Bugzilla – Bug 3199
chroot-ability for spells
Last modified: 2004-12-30 12:20:45 UTC
Hi, here are some patches to make it possible for spellwriters to let the spell be chroot'ed directly after installation. This can then be done by a <spellname>/chroot/ Directory containing build files for this purpose. A libchroot module is provided too, so this is easier to do. Eric / snakebyte
Created attachment 929 [details] patch for cast
Created attachment 930 [details] patch for libgrimoire
Created attachment 931 [details] the new module This is the last attachment for now. I have a modified version of the silc-server spell, if you want this too, just ask
What exactly do these patches do?
Hi, the spell writer can create a chroot directory inside a directory of a spell like /var/lib/sorcery/codex/devel/chat/silc-server/chroot, which contains alternative BUILD, PRE_BUILD & Co versions, which will then install the spell into a chroot directory /opt/chroot/silc-server/. The libchroot contains a function which makes it easy to copy the nessecairy libs into the chroot directory too. Then the deamon can be started chrooted, it is banned into the chroot directory, which is a useful security countermeasure. cu Eric / snakebyte
so whats the status on this? dropped? ignored? Or did you all just have as much spare time as I had the last few weeks... :) Eric
Free time? Hmm...I think I remember that. I haven't had much to test this with, perhaps apache2 would do nicely. :) Are the files in the <spell>/chroot/ directory different from those in <spell>/? If so, what is changed? If not, why have copies of them, just have a file 'CHROOT', similar to 'USEGCC2' (non-executable).
> Free time? Hmm...I think I remember that. ;) > I haven't had much to test this > with, perhaps apache2 would do nicely. :) Are the files in the > <spell>/chroot/ > directory different from those in <spell>/? The idea is to be able to place there additional ones, if they need to be different than those in <spell>/. If "chrootability" is selected and there is a <spell>/CHROOT/BUILD file it is used, if the file does not exist, it uses the <spell>/BUILD one. So If you need extra settings or other misc stuff to chroot the program, you can easily do it. > If so, what is changed? If not, > why have copies of them, just have a file 'CHROOT', similar to 'USEGCC2' Changes might be the creation of the directories in /opt/chroot/spellname/ which the spell needs, the copying of different misc files ( .conf or libraries ), in addition to this the entries for other config files are different ( xinet.d for example will now start "chroot /opt/chroot/spellname/ /bin/spell", instead of "/bin/spell" ) cu Eric
Moved to Feature Request as part of cleanup... erics
Is this work at all similar to the INSTALL_ROOT/CROSS_INSTALL stuff thats being developed? I dont want to leave this bug hanging forever if theres a similar solution being worked on.
Specifically no. This is a security enhancement, so daemons can be run in chroot to protect the host system. I don't know if any of the INSTALL_ROOT CROSS_INSTALL stuff is suitable or overlapping here though.
I'd like to close this bug because there 1) doesnt seem to be much need for this functionality, and 2) most of it can be provided with install_root and related variables. The only thing not provided is customization of configuration and xinetd files. However the few spells that seem to need similar functionality (bind) install in a chroot on their own without any help from sorcery. Since all this is anyways is a builtin query in CONFIGURE + conditionals in BUILD/INSTALL, theres seems to be little benefit in the additional complexity. If anyone wants or needs this functionality please speak up. If no one responds within a reasonable amount of time I'm going to close this bug out of lack of interest.
resolved as wontfix out of a lack of interest and necessity.