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-
