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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"