On Friday 21 November 2003 05:30, Dag-Erling Smørgrav wrote:
> Pawel Jakub Dawidek <[EMAIL PROTECTED]> writes:
> > I'm aware of this, but what we want to think over here is something
> > like in-kernel 'rm -P'. So file will be overwriten even if it is
> > opened and/or link count is grater than 0.
>
> That is not acceptable. First of all, it breaks a lot of assumptions
> in the filesystem code. Second, it is incompatible with the common
> technique of unlinking a temporary file immediately after opening it
> to avoid having it stick around if the process that created it dies
> prematurely. Your proposed change would thus reduce security rather
> than enhance it.
Right. The idea of restricting a file marked "secure" to not be able to
link to it, and refusing to set the flag if the file has a link count
greater than 1, is easy to do. I'm not sure it makes sense, though.
> Besides, overwriting the contents of a file when it is removed from
> the file system is not enough. You also need to overwrite every
> block or fragment which is released any time the file shrinks.
>
> Fortunately, ufs always truncates a file to length 0 when it is
> removed, so you only need to modify ffs_truncate() to implement both
> aspects (truncation and removal). You should also take care to
> overwrite the file's extended attributes if it has any.
For ffs, I believe it would be as simple as providing this behavior in
ffs_blkfree. Both the vnode and fs are passed to ffs_blkfree, so the
code should be able to check filesystem flags and/or file flags to
determine if the block should be erased before freed. This simplistic
approach would forgo some potentially very helpful optimizations,
though.
> Finally, I think a filesystem flag is much better for this purpose
> than a file flag; and in either case, file removal and truncation
> performance will be awful.
The filesystem flag is no more or less difficult to do; I can see doing
both for completeness sake.
As for performance, you really need to flush the on-device cache on each
pass to make sure the bit patterns get written to the platter in proper
order. I don't see any clever way to coalesce the writing of the
various patterns to multiple blocks short of a kernel thread, either,
so performance would be abysmal. Imagine removing a large file,
overwriting each block in 37 (IIRC) passes, syncing all the way through
the on-disk cache after *every block.*
Disk encryption suddenly doesn't look so bad, does it?
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
