From: Rob L. <ro...@la...> - 2005-04-27 02:27:29
|
On Saturday 23 April 2005 08:57 am, Blaisorblade wrote: > > By the way, I've toyed with the idea of running this sucker in an > > otherwise empty chroot environment (/proc/self/fd is likely to exist and > > have fairly uninteresting contents. As a chroot environment, it just has > > symlinks that point to nothing), but to chroot the UML kernel process > > from inside the initramfs, I need to come up with a new syscall. > > Ok, I now understand... chrooting it on the host! Yup. > > Can't do it before > > running the UML kernel because A) it needs to make its memory file, 2) it > > needs to access /proc/self/exe, III) it needs to loopback mount its > > executable file to pull the trick I just did. > > Not sure about this... you'll need to be root anyway to chroot, so you can > also (bind)mount what you need inside the chroot and unmount it later. Hmmm. You're right, that's sucks. I've also been thinking about some kind of wrapper that would be root, set up the environment, and run UML as a non-priviledged child process. Working out the details is a bit tough, though... > You > still need to ask UML to do this, yes, but it's different (also you could > even provide a simple module to load to do this, if the other ideas are > rejected at any level). Hmmm... I suppose I could always have a wrapper script that runs UML as a non-root process in the chroot environment and opens a named pipe that we can write into via hostfs when we want the chroot environment depopulated. (I vaguely recall there's a way to tell UML where to drop its memory file...) Better not to modify UML at all, if possible... Rob |