On Thu, 28 Oct 2010, Alexander Best wrote:
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?
Deleting data wasn't simple when rm -P was implemented -- in fact, if I
recall, there was significant information available even then that overwrite
patterns didn't fully remove file system data from magnetic media in such a
way that a qualified attacker couldn't recover it. Bad block relocation in
software and hardware is also relevant, and wear-levelling has been used in
certain storage devices for quite a while now as well.
Today the story has gotten even more complicated: file system snapshot
features, copy-on-write file systems, block device-level snapshot features,
widespread use of wear-levelling, full data journalling, etc.
But that doesn't mean that rm -P still isn't useful :-).
I see the point of the new pathconf() being to indicate whether trying to
overwrite file data is fundamentally useless. That information could be used
in one of two ways: (1) to warn the user that the requested overwrite is
unlikely to have helped and (2) to cause the removal to fail if it couldn't
possibly have worked. I find (1) more appealing but can see arguments for
(2); possibly both should be supported in some or another form.
Since there's a whole spectrum of confidence possible in whether an overwrite
succeeded, any mechanism like the one I've suggested is necessarily going to
involve fairly arbitrary heuristics. In a first generation implementation, I
suggest that rm -P should generate a warning only in the following case:
- An attempt to overwrite a file on a file system actively performing
copy-on-write that would affect the file, such as ZFS, or UFS when there's
an active snapshot.
After some further cogitation, and if people remain interested, the following
further case seems reasonable as well:
- An attempt to overwrite a file on a file system is mounted from a geom stack
in which at least one component in the stack is performing copy-on-write
that would affect the file.
The warning should read something along the lines of:
rm: /foo/bar: file system may not support data overwrite (-P
Or similar. However, rm should still perform the overwrite.
To be honest, I'm also fine with there just being a nice caveat in the rm(1)
man page. :-)
Robert
_______________________________________________
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"
