Re: about GNU Hurd

[olafBuddenhagen]

Hi,

On Mon, Sep 10, 2007 at 12:53:10PM -0400, Richard Stallman wrote:

>        One issue Marcus pointed out at some point is the infamous
>        firmlink problem, i.e. that a translator set by a different
>        user can lead to undesired behaviour. (If the user has a
>        symlink to '/' in /tmp or his home directory for example, an rm
>        -r on it launched by root would erase the whole file system.)
> 
>        This is probably a bug in the semantics of firmlink (it doesn't
>        behave as links are supposed to behave), and/or rm just doesn't
>        know how to handle links to directories correctly.
[...]
>        While Marcus was quick to conclude that translators are
>        generally problematic in a global filesystem, I believe this is
>        a pretty specific issue with the name resolution mechanism: The
>        real problem here is that the translator hands out an
>        unauthenticated object handle (capability), which the calling
>        program subsequently authenticates against it's *own* ID, i.e.
>        the translator is effectively able to hand out a capability
>        conveying more permissions than the user who created the
>        translator has.
> 
> I think you are right that firmlinks should be limited by the ID of
> their creator.

Not only firmlinks, but all translators. firmlink is just an example
Marcus used to demonstrate some more fundamental problems with the Hurd
design. And I am suggesting a solution to one of these problems.

> But I don't think that fully solves the problem.
> 
> Suppose you yourself create a firmlink from ~/foo/bar to ~.  And then
> you forget about it.  And then you do rm -rf ~/foo.  The firmlink's
> creator will be you, and you do have access write your home dir, so
> this will destroy its contents.

Yes of course. The change I suggested in handling of IDs is supposed to
adress the generic security problem that it's possible to create harmful
translators tricking other users into doing stuff the owner of the
translator couldn't do.

As I explained in the first part, I believe there is a more specific
issue with firmlinks though. However, I don't know the details how
firmlink works, so I can't point to anything specific.

Marcus once mentioned that rm first tries to unlink the node, even
before attempting recursion. This way symlinks are handled correctly.
This should work for firmlinks just the same: unlink() on the firmlinked
node should remove the firmlink, leaving the linked-to node untouched. I
don't see any fundamental problem with this approach.

> mv ~/foo /media/usb would also cause trouble, and so might some other
> programs that do recursive operations on subtrees.
> 
> So we still need a solution, and I don't know if there is one.

Indeed, while I believe that most of the security concerns can be fixed
by changing the ID handling, and rm -r on firmlinks can be fixed by
fixing the semantics of firmlink to behave like other link types, there
are other problems with firmlinks and translators in general as well.

Recursive links are generally a problem. In fact, in some discussion I
once read, this was mentioned as the major reason why most UNIX systems
don't allow hardlinks to directories. And the same problem exists with
symlinks as well -- the only reason symlinks work most of the time, is
that many programs are aware of them and handle them specially.
Nevertheless, recursive symlinks still cause trouble in some situations;
I experienced that myself with GNU/Linux.

On a more general scale the problem is, as Marcus puts it, that programs
expect very specific behaviour from filesystems: That filesystem
operations always finish in a finite amount of time; that files always
have bounded size; that the directory structure is consistent and has no
loops; etc. Translators can violate any of these assumptions, resulting
in potential trouble. One example he gave is the question how backup
tools are supposed to cope with a filesystem containing translators.

I addressed this problem also in this mystical draft mail. The simple
solution for most cases is just to not let programs see such problematic
translators most of the time. Not only because it can be dangerous, but
simply because it usually just doesn't make sense.

When this issue once came up on the bug-hurd list a while ago, Roland
mentioned that the idea is to have translators presenting an alternative
view of parts of the filesystem, identical to the standard view, except
that some or all of the translators are disabled.

An interesting variant would be a possibility to choose between
translated and untranslated versions of a file by appending special
suffixes to file and directory names. (In fact I believe this to be
useful enough that it might be worthwhile adding such an ability
directly in the standard name resolving mechanism...)

Interestingly, although I have been considering such mechanisms for a
long time, and came up with most of my ideas how to handle that myself,
some people on the l4-hurd list came up with very similar ideas
independently in the context of ngHurd. (Though with a different
motivation.) I think this is an example nicely demonstrating that the
Hurd architecture is powerful enough to allow adding many desirable
features without changing the underlying design.

-antrik-