Date: Thu, 28 Oct 2010 18:22:19 +0000 From: Alexander Best <arundel@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Doug Barton <dougb@FreeBSD.org>, d@delphij.net, svn-src-all@FreeBSD.org, Gary Jennejohn <gljennjohn@googlemail.com>, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au>, svn-src-head@FreeBSD.org, Dag-Erling Smorgrav <des@FreeBSD.org> Subject: Re: svn commit: r214431 - head/bin/rm Message-ID: <20101028182219.GA36559@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1010281845030.58253@fledge.watson.org> References: <201010271848.o9RImNSR019344@svn.freebsd.org> <20101027212601.GA78062@freebsd.org> <4CC899C3.7040107@FreeBSD.org> <20101027214822.GA82697@freebsd.org> <4CC8A89D.5070909@delphij.net> <20101028152418.A916@besplex.bde.org> <20101028095538.24147119@ernst.jennejohn.org> <alpine.BSF.2.00.1010281845030.58253@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu Oct 28 10, Robert Watson wrote:
> On Thu, 28 Oct 2010, Gary Jennejohn wrote:
>
> >>>The -P option assumes that the underlying storage overwrites file block
> >>>when data is written on existing offset. Several factors including the
> >>>file system and its backing store could defeat the assumption, this
> >>>includes, but is not limited to file systems that uses Copy-On-Write
> >>>strategy (e.g. ZFS or UFS when snapshot is being used), or backing
> >>>datastore that does journaling, etc. In addition, only regular files
> >>>are overwritten, other types of files are not.
> >>
> >>Summary: it is very hard to tell whether -P works, even when you think
> >>you know what all the subsystems are doing.
> >
> >All this discussion leads me to the conclusion that we should just remove
> >the -P functionality and add a remark to the man page that that was done
> >because it isn't guaranteed to work on all file systems.
> >
> >Why give users a false sense of security? If they're concerned about data
> >security then they should use geli or something similar.
>
> I'm not sure I entirely agree with this conclusion: there are times when -P
> can be quite effective at removing data from a system, and not having it
> available when it could work might also be problematic.
>
> Part of the problem here is that we have successfully abstracted away a lot
> of information going up the storage stack. One possibly solution to this
> problem is to add ways for that information to propagate better -- in the
> same way that the end-to-end argument in network design is moderated by the
> reality that performance can be dramatically improved if information
> gathering can be done with an awareness of lower layers (for example, PMTU
> discovery), even if decisions about how to use that information are at the
> endpoints only.
>
> For example, you could imagine a pathconf() call that asks the file system
> if overwriting a file is likely to result in the data going away -- UFS
> could answer "yes" unless it's snapshotting the file system, and ZFS could
> simply answer "no".
>
> In FreeBSD 9, we're going to have two common file system configurations:
> ZFS and UFS+SUJ; the latter will do overwriting of files just fine on most
> current media.
i agree. however from this discussion it's become quite obvious that securely
deleting any data on a certain media is a very complex topic. when the -P
option got implemented into rm, securely deleting files was quite an easy and
intuitive task. this has clearly changed. so the question arises, if securely
removing data (maybe also directory entries) shouldn't be handled by a
specially designed utility?
the pathconf() idea looks very primising. should the return values ("yes" or
"no") simply be hardcoded for every fs? or should they be returned by a routine
which actually veryfies on the fly if overwriting files is possible?
alex
ps: please keep in mind that an import of fusefs might happen in the next few
months, so the fs situation on freebsd might change.
>
> Robert
--
a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101028182219.GA36559>