Hi, I am still not subscribed to this list, it is still not the primary forum to discuss these issues. This mail is about firmlink and rm -fR.
firmlinks and rm -fR are a usability (and potential security) catastrophy, because translator settings are designed to be transparent to POSIX applications. This transparency is often desired. But in some cases, it can lead to unexpected consequences. As such, they violate the principle of least surprise. Some reasonable assumptions: System administrators expect rm -fR /tmp/* to delete the temporary files and directories, and nothing else. Users expect rm -fR /some/dir to delete everything below this dir and the directory itself, but nothing else. firmlinks within these directories pointing outside them violate these assumptions. Should rm know about translators and delete them before deleting the underlying file? Clearly, this would address this specific scenario. But it does not address similar issues with other applications. Maybe only a limited number of applications is affected, but we can not say this for sure. Also, such a statement raises a big warning light: We are not talking about extending the functionality of the program "rm", but implementing it correctly, that means: according to the user's expectation. Did the original programmers of rm make a programming mistake by not considering translators? Certainly not. The issue here is that translators break compatibility with POSIX programs in the sense that their semantics violate programmer's deep assumptions about the interfaces of the system. Not just the syntax of the POSIX ABI needs to be provided for compatibility, such as the function names and which argument goes where, but also the semantic behaviour of these functions in the environment they operate, and assumptions about that environment. POSIX programmers assume that normal users can not add strange file system objects like firmlinks (and other, more devilish objects) to the global name space, so programs like rm and locate and find and many other programs are written without considerations for these possibilities. There is a related issue, which is worth pointing out: The Hurd objects are polymorph. For example, a file node can also act as a directory. This has also caused a couple of bugs over the years. Here, also the issue arises if a legacy application like tar should access such a polymorphic node as a directory or as a file. How it will behave is pure luck, and depends on the translator's behaviour as much as on tar's detection mechanism. I remember that rm -fR was deleting a firmlink instead of recursing into it in one specific circumstance due to a small peculiarity of its implementation: It looked at the type information in the directory entry rather than the inode to decide how to behave (and in the Hurd, of course, the two don't need to match!): To recreate the rm+firmlink problem, you must make sure the firmlink is attached to a directory node rather than a file node. Who would have guessed? If you look at the polymorphy issue, you will quickly decide that what should happen in general needs to be decided by the user, but the decision might depend on any number of factors like intent, application, phase of the moon, etc. Again, the potential for polymorphy was not considered by POSIX programmers, so POSIX applications do not expect files to be polymorphic: rm uses the direntry type info and expects it to be the same as the inode type entry. Legacy compatibility requires that these two be the same, and the Hurd does not implement that, in fact, can not implement it in general (because Hurd objects are not limited to a small number of system-provided types). How should one "fix" such an issue? It's not really about firmlink after all. It's about legacy interfaces and compatibility. Depending on your point of view, you can draw different conclusions: Those who want a high degree of legacy compatibility will want to remove Hurd functionality from the "sight" of POSIX applications. Those who take a more relaxed view will favor functionality over compatibilty. But, the firmlink+rm security problem (rm -fR /tmp) shows that in general it is very hard to predict which applications will stumble over which issues, and the security and usability implications are daring. A simple fix to the security issues is to not follow translators which are attached on nodes owned by a different user than 0 and one's own UID by default. This limits sharing of user created Hurd objects to those people who explicitely enable it. That is kinda sad, but at least for the system administrator and daemon programs (apache) this is an absolute must if you value correctness at all. A more complicated fix is to modify each application to be written against the new Hurd interfaces rather than POSIX interfaces. This requires much more effort, but might be more rewarding. The polymorphy issue can be handled by providing different "views" on the same object: The underlying object could be accessed through a "file" view (a node that looks like a proper file) and through a "directory" view ( a node that looks like a proper directory), and POSIX applications would therefore see one or the other, but would not be confused. The user would have to provide explicit names to select different views. Unfortunately, POSIX pathname syntax does not allow for such extensions, but if one is willing to reduce compatibility, one could settle on something that does not commonly occur, like "foo^^^as-file" and "foo^^^as-dir/" (just an example, make up your own). I do not think that it is necessary to settle on a single approach to deal with these issues. There are trade-offs involved, and different environments call for different solutions. But even for any particular environment the issues are not simple. The above suggestions (limiting transparent access, explicit naming) are thus merely provided as starting points and illustrations. Note that the disadvantage goes in both directions: The Hurd suffers from the lack of portability of POSIX applications to new environments. But POSIX suffers from its lack of extensibility. Of course, the alternate point of view is that POSIX mandates that "everything looks like a file". This was a good strategy when all user-computer interactions were file or stream based. But modern desktop environments seem to call for more complex component models (eg COM (== Windows), GNOME, KDE). In light of this it is not a surprise that GNOME has moved to its own platform/architecture. Thanks, Marcus
