Date: Sun, 31 Oct 2010 20:57:57 +0100 From: Ulrich Spoerlein <uqs@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r214596 - head/bin/rm Message-ID: <20101031195757.GO46314@acme.spoerlein.net> In-Reply-To: <20101031195003.GE2160@garage.freebsd.pl> References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl> <20101031191119.GM46314@acme.spoerlein.net> <20101031195003.GE2160@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 31.10.2010 at 20:50:03 +0100, Pawel Jakub Dawidek wrote: > On Sun, Oct 31, 2010 at 08:11:19PM +0100, Ulrich Spoerlein wrote: > > On Sun, 31.10.2010 at 17:06:03 +0100, Pawel Jakub Dawidek wrote: > > > IMHO this option should be removed and rm(1) should fail when a user is > > > trying to use it. > > > > No, this is a POLA violation for no apparent gain. The flag has been in > > FreeBSD since at least '94. Remember, that we are in the rope-selling > > business. We empower the users to shoot themselves in the foot. > > > > I, for one, am using the -P option in a certain case where I can be sure > > that ~99% of the data will be obliterated and I'm fine with that. For > > all other cases I'm using geli or gbde (where I can make sure, that data > > is lost). > > The question remains unanswered: If it is not a security feature then > what's the purpose? > > IMHO this is a security feature, just a really lame one. Too many > requirements have to be meet to make it work. > > I don't think you would want to read in GELI or GBDE manual page that it > encrypts the data sometimes, or if all the given requirements are meet. > Of course requirements are fine, but they have to be really clear to the > user and the list should be as short as possible, which is not the case > here. True, this was obviously the case when the feature was introduced, a couple of years ago. As things change constantly, it may never be possible to have it work (and not break silently in the future). > > So we can either fix -P for all cases (impossible), or at least document > > its shortcomings. Documenting them clearly is better than what we had a > > couple of days before. > > I don't argue that the previous version of manual page was better I just > pick your commit to discuss it mentioned functionality further. Sorry, if my post came across a bit harsh. I only tried to document the current behaviour a bit more clearly, and perhaps give the user a warning that this feature might not do what it did 16 years ago. > Maybe we could implement few simple checks which when satisfied don't > emit a warning, ie. if this is UFS, on top of partition, on top of a > slice and on top of a regular SCSI or SATA disk don't emit a warning, > but if there is a doubt, do emit a warning. This might not be trivial, > but might be doable. Alternatively we could always emit a warning. Knock yourself out, code speaks louder than words ... Uli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101031195757.GO46314>