On Mon, 2007-09-10 at 19:55 -0400, Richard Stallman wrote: > * Simply don't allow setting passive translators inside a chroot at > all. After all, chroot is only for UNIX compatibility, and > translators are not a UNIX concept... > > This doesn't do the job. Suppose someone creates the passive translator > or firmlink in the directory, and later you do a chroot to that directory. > The problem will happen. >
In addition, firmlinks are needed for full support for features like networking in chroots. You need to make a firmlink from /server/sockets/2 to *chroot*/server/sockets/2 if you want the network to work. In addition, due to Hurd architecture, if we want full network support inside a chroot, we'll need to either redo how networking is done in heard (get rid of /server/sockets/2), or provide a mechanism to share servers/sockets/etc, between the chroot jail and the base system. I think the same problem exists in sub-Hurds, although someone with more experience will have to comment. > In other words, this is not about creating a firmlink while chrooted, > it is about the existence of a firmlink inside the chroot directory. > > * Allow setting passive translators, but only temporarily, not > storing them in the underlying filesystem. When accessing the > translated node, the translator is started by the chroot. > > I don't really follow that. > > * Store the passive translator, but also store the chroot > information; and only start the translator if the node is accessed > from within the same chroot. > > The next one is clearly better than this one. > > * Store the passive translator and the chroot, and whenever the node > is accessed, run the translator in a matching chroot. This might be > the most elegant solution. > > This doesn't seem to address the case that someone else makes a > firmlink in the directory that you are chrooted to. > > * Last but not least, we could simply allow setting passive > translators from within a chroot normally like it happens now, but > when a translated node is accessed, the translator started would > run in the context of the process accessing it -- which is > different for a chrooted process than for a normal one. > > That one makes sense. I see another that also makes sense: > > * If a firmlink points to a place outside the chroot, treat it as if > it pointed to a nonexistent file. This should only be the case for passive instances of the firmlink translator. The active one should be allowed to point outside the jail if needed. > > That way, it can never point to the "wrong" file. > > > The main question is, does anyone know of any flaws in these solutions? > >
