svn commit: r214431 - head/bin/rm

[Robert Watson]

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