Re: rm patch suggestion

[Marcus Brinkmann]

On Wed, May 08, 2002 at 12:01:09AM +0200, Niels Möller wrote:
> > 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).
> 
> I think there are other cases as well, in particular with with group
> writable directories. For example, consider rm -rf
> /usr/local/share/emacs/20.7, where all of /usr/local is writable by
> the staff group.
>
> Sure, it's reasonable to assume that you haven't given malicious users
> write access to /usr/local,

Not only that, but it is also reasonable to assume that you actually trust
all members of the group and agreed upon a policy how to set up the system.
I don't really think that there shouldn't be a way to be lazy, eg, you don't
want to really check if there are some (well meaning) translators, and just
want rm to do the right thing.  But in this case, I tihnk it is reasonable
to require setting some extra flag, as well, if it makes sense to implement
it that way.

> but you could still do some unexpected
> damage if some other user have installed translators in the tree (e.g.
> say some shadowfs-thing installed somewhere in the site-lisp
> directory). You don't want to accidentally mess with that, just
> because you think emacs 20.7 is obsolete and should be purged from the
> system.

Either you set up shadowfs readonly, or you know that shadowfs is used and
delete the underlying store.  Or shadowfs implements unlink by hiding the
files, so there is no harm done.  I don't really want to discuss this
specific case, but I think it is well worth noting that there are a lot of
details in such cases that are relevant, and that most are better solved by
local policy + offering all possibly useful features in the tools to make
implement the policy easy for the users, and having simple to understand
default rules (the default behaviour should certainly be as transparent as
possible!).  Mmmh.  rm should have an -n, --dry-run option that simulates the
action done :)

I think your comment on that we need to decide on a reasonable default was
very important, and input from people with experiences as admins or users of
complex group systems is very useful (I am mostly a single user).  I think
what you raised above might be a good reason to only follow translators by
default that are actually owned by you, so even if it is someone from the
same group, you won't follow it if you didn't set it up yourself (or gave
permission to).

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