Re: The safety expansion for FreeBSD rm(1)

From: Daichi GOTO <daichi_at_freebsd.org>
Date: Thu, 27 Sep 2007 21:10:18 +0900
Oh yeah--it's an interesting point, and we are going to think
about it :)

ttw+bsd_at_cobbled.net wrote:
> Daichi GOTO <daichi_at_freebsd.org> wrote:
> [ ... ]
>> 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.
> 
> this is a nice little feature but from an administrative point of view
> i don't think it will be used (i'm infallable, as are most admins
> ... at least within their own heads) and there are other more
> comprehensive (i.e. not just the rm binary) tools for critical paths
> (as others have pointed out).  from a user perspective it would be
> nice to have '/etc/rm.conf' or something so the admin can prevent user
> foot shooting, however, how many user deletes will actually be performed
> by 'rm'.  basically, it's very clever, non-intrusive feature but i
> just can't see any value from it.
> 
> perhaps if, instead of overlapping the current flags function, you
> used this feature to allow the user to be prompted when deleting a
> 'uunlink' file, or so that a user may set places where 'rm' will
> effectively ignore the 'uunlink' flag.  still not sure how much value
> but it may encourage the use of 'uunlink' so that more paths are
> protected (i.e. if more binaries are flags aware we don't need to
> constantly change flags to perform functions).  one obstacle i can
> think of is that many files may be stored on filesystems incompatible
> with flags.
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

-- 
   Daichi GOTO, http://people.freebsd.org/~daichi
Received on Thu Sep 27 2007 - 10:10:19 UTC

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