Re: about GNU Hurd

[olafBuddenhagen]

Hi,

On Fri, Sep 07, 2007 at 03:53:18PM -0400, Richard Stallman wrote:

>     This depends on what issues you are refering to.  The two
>     (semi-serious) problems that Marcus pointed out wrt to passive
>     translators and firmlinks can be solved.  As was pointed out by
>     Bushenell, and someone else.
> 
> I would like to see these solutions. Could someone please show them to
> me?

Regarding the chroot issue, I have written up some ideas at

   http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html

Marcus skimmed over it once, but didn't give a detailed reply, so I'm
not sure what he thinks about it.

Regarding firmlinks, let me quote a bit from the draft of an email I
once meant to send:

   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. In both cases I guess
   that's not too hard to fix, but of course it wouldn't remove the
   underlying problem, that it's possible to write such a harmful
   translator. So, what's going wrong here?

   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. Thus a confused program
   can be tricked into doing things that the translator itself (or the
   user owning it) would not be allowed to do.

   I believe this is a fundamental error -- AIUI, it violates the idea
   of capabilities, which should always convey the same permissions, no
   matter how much they are passed around. To fix this, the name lookup
   mechanism needs to be modified, so that translators always return
   capabilities bound to the translator's UID. I hope this shouldn't be
   too hard to do, and shouldn't affect the rest of the Hurd design in
   any major way.

Note that I haven't actually tested this, nor discussed it with others;
so I'm not sure it's really the correct conclusion... Just something to
consider.

-antrik-