firmlinks and rm -fR

[Marcus Brinkmann]

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