Re: Chroot and ".."

[Marcus Brinkmann]

At Thu, 13 Oct 2005 11:48:53 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:

> > But in the Hurd, a directory capability allows you to look up the
> > special filename "..", and this gives you a capability to the parent
> > directory.
> 
> It does not, and it cannot. It cannot do this in UNIX either. The reason
> it cannot do this is that the entire concept of ".." in the file system
> is completely broken. It assumes that every directory has at most one
> parent. Here are some examples of violations of your assumption from
> UNIX:

[...]

I think you could add symbolic links to your list of examples.  They
too seem to create more parents for directories, although they are not
completely transparent.

> Somewhere around 1986, Dave Korn and Emden Gansner argued strongly that
> ".." was completely busted, and that the only sensible implementation
> was to represent CWD (logically) as a string and implement ".." as a
> string to string transformation in namei() [at that time, namei()
> implemented the inode path walk code]. That is, they argued that ".."
> could only be given a sensible meaning if it was context sensitive. One
> of his arguments, in fact, concerned the problem with chroot() that has
> been discussed here.

[..]

> > We need thus two types of directory capabilities.  One that allows
> > looking up "..", because that is still useful in many contexts.  And
> > one that is the "secure" version and disallows looking up "..".
> 
> I think that the Korn/Gansner proposal is a better solution, because the
> hierarchy assumption that underlies ".." is wrong.

Ok.  I think you (and Korn/Gansner) make a very strong point.  After
all, as you say, the shells already implement this behaviour.  If you
have a directory structure foo/bar/ and a link baz -> foo/bar, then
there is a difference between 'chdir baz/..' in the shell and 'chdir
("baz/..");' in a C program.  I have to admit that I don't write much
C code dealing with directory traversal, and I find the shell
behaviour quite useful and appropriate.
 
> WHAT EROS DOES:
> 
> > How would you do it in the EROS filesystem?
> 
> In EROS, directories do not have the ".." entry. We cannot, because we
> don't impose a hierarchy restriction. A directory is simply a set of
> mappings from strings to capabilities where the strings are disjoint.
> 
> Our directories *do* implement a "." entry, mainly because it was easier
> to seed the directory data structure that way.
> 
> For emulation purposes, I would adopt the Korn/Gansner design.

Actually, I think that the Korn/Gansner design is the right approach
for a good native interface.  I am not sure that it is a good
emulation if compatibility is required.  The POSIX VFS stuff is very
hairy, and even small differences cause a significant number of
incompatibilities, as past experience has shown.  I am not sure how
big the tolerance in the Unix application writer world is for
potentially big differences (ie for getting patches incorporated
upstream).  We have some experience with this, because the Hurd
adopted some conventions from earlier BSD systems, and very few small
differences in path name resolution caused porting considerable work.

Here is one of the potential pitfalls I see: If you adopt the
Korn/Gansner design, I suppose that in the application (ie, in the C
library), you keep a string that is associated with the current
directory capability.  Presumably, you hope, the string denotes the
absolute path name under which this capability can be received from
the root directory capability, which is also associated with the
current directory (this may be a different root capability than the
POSIXish root directory).

Let's say the program wants to resolve a relative path starting with
"..".  Here would be one way to do this: Prepend the string associated
with the current directory, replace every "foobar/../" in the pathname
with the empty string (foobar must not be "." or ".." of course),
recursively.  The resulting absolute pathname is looked up from the
root directory.

Is there a performance concern here in always looking up absolute
paths?

If one of the parent directories is renamed, you have to update the
string in each application that has a current directory within the
renamed directory tree, or you are in danger of looking up the wrong
directory or not finding your original directory tree anymore.  The
same could happen on Unix if you use absolute pathnames, but in Unix
you have the option to use relative paths instead, giving you some
protection.  I am not sure how many applications are written carefully
enough to allow dynamic relocation, but there must be at least some
(just because there are so many POSIX applications).

Ok, so let me try to fix this: Instead of looking up the whole path
from the root, we cache every level of the directory hierarchy in our
path:

Current directory /foo/bar/baz from ROOT

Cache:
ROOT_FOO is the foo directory cap.
ROOT_FOO_BAR is the bar directory cap
ROOT_FOO_BAR_BAZ is the BAZ directory cap.

Now, if you want to look up for example "../fum", you construct the
absolute path name "/foo/bar/fum", recognize that "/foo/bar" is in the
cache and use the ROOT_FOO_BAR object to look up "fum".

Even if the directories are renamed, you will always use the right
directory capability.

So far, so good.  The problem is that caching can introduce other
compatibility problems, because sometimes applications want to _see_
the new directory that was renamed into the place of an old directory.
Again, I don't have an example, but there must be at least some.

Maybe this is an acceptable cost, and Korn/Gansner is good enough in
the real world to get most programs working without problems.  We
would have to find out.  I think it is well worth to investigate this
further.

Even for the native interface I don't know if you would want caching
in the application or not.  Probably depends on where you store the
VFS.

Thanks,
Marcus