Re: The safety expansion for FreeBSD rm(1)

From: Brooks Davis <brooks_at_freebsd.org>
Date: Tue, 25 Sep 2007 13:33:13 -0500
On Tue, Sep 25, 2007 at 07:40:08PM +0200, cpghost wrote:
> On Tue, 25 Sep 2007 21:58:37 +0900
> Daichi GOTO <daichi_at_freebsd.org> wrote:
> 
> > Today is not unionfs. Introduction for safety expansion of rm(1).
> > I know that some unix folks have a experience that you remove some
> > files or directories accidentally. Yes, me too. LoL
> > 
> > Have you any dreams that rm(1) autonomously judges target should
> > be remove or not?  To complexify system base command is objectionable
> > behavior but adding some little and simple mechanism to prevent a
> > issue is acceptable I suppose.
> > 
> > We have created safety expansion for rm(1). If you have any interests,
> > please try follow patch.
> > 
> >    http://people.freebsd.org/~daichi/safety-rm/
> > 
> > Thanks :)
> 
> Interesting idea, but isn't that a violation of POLA? Imagine an
> unsuspecting sysadmin trying to rm something, and forgetting
> or not knowing about ~/.rm?

All they have to do is specify -f and ~/.rm is ignored so I don't think it's
that big a deal.  It does raise the potential of werid side effects in scripts,
but since you have to deploy ~/.rm files for anything to happen, I don't see it
as that big a deal.  It might be useful to have the ability to turn off ~/.rm
support via an environmental variable.

> Isn't it better to protect important system directories with
> something like:
>   # chflags sunlink /path/to/dir
> and unprotect them with
>   # chflags nosunlink /path/to/dir
> to avoid mistakes?

The above change means you have to apply the hammer of chflags to do
anything.  The patch lets you specify certain directories where you're
prompted instead.  I see that as much more useful.

-- Brooks

Received on Tue Sep 25 2007 - 16:33:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC