svn commit: r214596 - head/bin/rm

[Ulrich Spoerlein]

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