secure deletion
Javier Henderson
javier at KJSL.COM
Fri May 21 18:10:09 GMT 1999
brooks at one-eyed-alien.net writes:
> On 21 May 1999, Dag-Erling Smorgrav wrote:
>
> > "Ilmar S. Habibulin" <ilmar at ints.ru> writes:
> > > Why mount option? Secure deletion is a feature of fs and impacts files of
> > > this on this fs. All of them. So why use mount option?
> >
> > Because a mount option can be changed at runtime, whereas a kernel
> > option cannot. A mount option would allow you to enable the security
> > feature on file systems which need it but not on file systems which do
> > not need it, whereas a kernel option would enable it unconditionally
> > on all file systems.
>
> I'd definaly agree that it should be done on an FS by FS bases, but it
> seems that a tunefs flag like softupdates might be more appropriate. My
> reason for this is simply that if you forget to enable the option once and
> do any write operations to speak of, you will need to completly wipe the
> entire FS to ensure you actually destroy the old data. Making it a tunefs
> option would mean that you couldn't forget.
Just in the interest of throwing ideas around, and not to start
an OS war:
With VMS, you can define at mount time, or at any time
afterwards (ie, while the volume is already mounted) whether you want
files erased-on-delete or not. If you change the behavior at some
point after mounting the volume, the new behavior will affect
deletions made after the change of behavior.
There is also a CLI qualifier for the DELETE command,
appropriately named /ERASE (e.g., DELETE/ERASE FOO.TXT) that you can
use on demand.
This kind of flexibility would be cool, I think.
-jav
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message
More information about the posix1e
mailing list