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-
