svn commit: r214596 - head/bin/rm

[Ken Smith]

On Sun, 2010-10-31 at 20:11 +0100, Ulrich Spoerlein wrote:
> On Sun, 31.10.2010 at 17:06:03 +0100, Pawel Jakub Dawidek wrote:
> > On Sun, Oct 31, 2010 at 09:21:28AM +0000, Ulrich Spoerlein wrote:
> > > Author: uqs
> > > Date: Sun Oct 31 09:21:27 2010
> > > New Revision: 214596
> > > URL: http://svn.freebsd.org/changeset/base/214596
> > > 
> > > Log:
> > >   Elaborate some more on the non-security implications of using -P
> > [...]
> > > +.Pp
> > > +N.B.: The
> > > +.Fl P
> > > +flag is not considered a security feature
> > > +.Pq see Sx BUGS .
> > 
> > I'm sorry for jumping so late into the subject, but if it is not a
> > security feature than what other purpose has left?
> > 
> > Really guys, this option is useless.
> > 
> > There is no reliable way to verify if the blocks are really overwritten.
> > Period.
> > 
> > If it is not used for security, then I see no other use for it (except
> > for [1]).
> > 
> > If it is used for security then we better have a way to give the user
> > the right answer to the question "is my data really gone?" and don't
> > make false assumptions or giving answers "we hope so".
> > 
> > Why there is no reliable way to verify this?
> > 1. Check file system type (UFS, ZFS).
> > 2. Check file system configuration (UFS with snapshots?).
> > 3. Be sure sync(2) the file system and send BIO_FLUSH to all the media
> >    involved (some cheap flash disks lie about BIO_FLUSH support).
> > 4. Check underlying media (GLABEL provider - no modification to the data).
> > 5. Check underlying media (ZVOL - data won't be overwritten, but...).
> > 6. Check ZFS vdevs (on which providers ZVOL's pool is based on).
> > 7. Check vdevs (GELI - cool, we have encryption).
> > 8. Check GELI configuration (maybe NULL encryption algorithm?).
> > 9. Check underlying media (HDD, SSD, swap-backed md(4) device? goto 3).
> > 10. Check if the sectors weren't remapped while we were overwriting.
> > 
> > In other words this is soooo complicated that it would simply be too
> > hard to explain to regular user or implement in rm(1).
> > 
> > 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.

Just playing Devils' Advocate...  If the removal of -P were done as
part of a new branch the POLA argument is moot if it's judged you
are a bit off on the "no apparent gain" aspect.  And the rope selling
argument also only applies so far.  One could argue having our installer
by default leave a machine set up so SSH was enabled, remote root logins
were allowed, and no initial password set up for root is fine because
we're in the rope-selling business and for some portion of the user
base that's just fine.  I know that's extreme but that's the point,
I'm saying it's hard to figure out exactly where the line is between
activities that are ill-advised versus those that are just plain
stupid sometimes.

So, please, given all the attention being given to the security aspects
of users properly erasing data they should erase I'd prefer we focus on
whether providing -P at all is flat out lying and base the decision
about whether it should go based on that.  Lots of things we thought
were OK back in 1994 we've changed our minds about since then.

> 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).

This strongly backs up Pawel's argument that the existence of -P is a
lie.

> 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.

As I said above, with re@ hat on since the claim of POLA above is
slightly based on branch/release guidelines, I think removal of -P
is also still an option if it's decided -P is a lie.

-- 
                                                Ken Smith
- From there to here, from here to      |       kensmith at buffalo.edu
  there, funny things are everywhere.   |
                      - Theodor Geisel  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20101101/96b3d65f/attachment.pgp