Date: Tue, 25 Sep 2007 13:33:13 -0500 From: Brooks Davis <brooks@freebsd.org> To: cpghost <cpghost@cordula.ws> Cc: Daichi GOTO <daichi@freebsd.org>, Masanori OZAWA <ozawa@ongs.co.jp>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: The safety expansion for FreeBSD rm(1) Message-ID: <20070925183313.GB78038@lor.one-eyed-alien.net> In-Reply-To: <20070925194008.3c2d7113@epia-2.farid-hajji.net> References: <46F905FD.9060208@freebsd.org> <20070925194008.3c2d7113@epia-2.farid-hajji.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 25, 2007 at 07:40:08PM +0200, cpghost wrote: > On Tue, 25 Sep 2007 21:58:37 +0900 > Daichi GOTO <daichi@freebsd.org> wrote: >=20 > > 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 > >=20 > > 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. > >=20 > > We have created safety expansion for rm(1). If you have any interests, > > please try follow patch. > >=20 > > http://people.freebsd.org/~daichi/safety-rm/ > >=20 > > Thanks :) >=20 > 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 scri= pts, but since you have to deploy ~/.rm files for anything to happen, I don't se= e 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 --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFG+VRoXY6L6fI4GtQRAlfpAJ9Exv7yLuGmqFhqqno/DQkLRzspjwCfQwko b7dA8pUxmh1M3p+ZnzqpTCc= =ZlGD -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070925183313.GB78038>