On Sun Oct 31 10, 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.
i suggested to remove it and also came up with a patch [1], but quite a lot of developers decided the -P option should be kept rather than removed. although there was quite an elaborate discussion about it that followed after des@ commited r214431, i still haven't got the slightest idea just WHY it should stay. ;) [1] http://www.mail-archive.com/svn-src-head@freebsd.org/msg07404.html cheers. alex > > 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. > > [1] When we have UFS file system on top of ZVOL with compression > enabled, overwriting file content with zero bytes should convert blocks > into holes, which will free some space - a usage definitely not worth > keeping -P around. :) > > -- > Pawel Jakub Dawidek http://www.wheelsystems.com > p...@freebsd.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! -- a13x _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
