Re: rm patch suggestion

[Marcus Brinkmann]

On Tue, May 07, 2002 at 05:08:58PM +0200, Oystein Viggen wrote:
> Problem is, you never ever want to recurse into directory translators
> belonging to other people,

Make this "you never want to recurse into directory translators" of
untrusted people.

The general concept in Hurd is: Make translators as transparent to Unix as
possible.  Your change is conflicting with this.  I think it might possibly
be better to have an option to enable this behaviour, rather than make it
the default on some combinations of traditional flags.

This problem should, for traditional Unix usage, only crop up in two
situations: Removing files in /tmp, removing a user's home directory (or
files in there).  Both is only commonly done by the sysadmin, who will not
find it hard to learn the one new option to rm to make these safe operations
(of course, it should be visibly documented in the Hurd docs).

For all other users, the default is to not allow anyone to meddle with ones
files, so they are safe if they are careful.

You have one strong argument in favour of your change though: And that is
that rm -fR does not follow symlinks either.  I want to cite a comment from
glibc/hurd/lookup-retry.c (which I pointed to in the prior discussion about
this topic, IIRC):

              if (flags & O_NOFOLLOW)
                {
                  /* In Linux, O_NOFOLLOW means to reject symlinks.  If we
                     did an O_NOLINK lookup above and io_stat here to check
                     for S_IFLNK, a translator like firmlink could easily
                     spoof this check by not showing S_IFLNK, but in fact
                     redirecting the lookup to some other name
                     (i.e. opening the very same holes a symlink would).

                     Instead we do an O_NOTRANS lookup above, and stat the
                     underlying node: if it has a translator set, and its
                     owner is not root (st_uid 0) then we reject it.
                     Since the motivation for this feature is security, and
                     that security presumes we trust the containing
                     directory, this check approximates the security of
                     refusing symlinks while accepting mount points.
                     Note that we actually permit something Linux doesn't:
                     we follow root-owned symlinks; if that is deemed
                     undesireable, we can add a final check for that
                     one exception to our general translator-based rule.  */

So, for rm, it might similarly be a good thing to follow root owned
translators, or maybe even all translators that run on a node owned by the
current user (eg, those would count as being trusted), possibly both.

This is something we have to think more about.  Maybe a general rule like:
If you would normally not follow symlinks in Unix for security, don't follow
translators not owned by root/you/either of them/... as well.

> It would be interesting to hear more opinions on how rm should behave.

We might not find out but by trying, experience, and smart people like you
who identify the problems/attacks/etc... this can take some time :)
I hope with the connection to O_NOFOLLOW I could give some hint where
similar problems occur, and maybe the relation is strong enough to hold
some water.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de