[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
chroot issues and http://tri-ceps.blogspot.com/2007/07/theory-of-filesys
chroot issues and http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html
Mon, 10 Sep 2007 19:55:13 -0400
* 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 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.
That way, it can never point to the "wrong" file.
The main question is, does anyone know of any flaws in these solutions?
- chroot issues and http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html,
Richard Stallman <=