From owner-freebsd-security Fri May 21 11:10:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from bogon.kjsl.com (bogon.kjsl.com [205.179.23.2]) by hub.freebsd.org (Postfix) with ESMTP id 32C4715111 for ; Fri, 21 May 1999 11:10:16 -0700 (PDT) (envelope-from javier@bogon.kjsl.com) Received: (from javier@localhost) by bogon.kjsl.com (8.9.3/8.9.3) id LAA25276; Fri, 21 May 1999 11:10:09 -0700 (PDT) From: Javier Henderson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14149.41345.818718.833426@bogon.kjsl.com> Date: Fri, 21 May 1999 11:10:09 -0700 (PDT) To: brooks@one-eyed-alien.net Cc: Dag-Erling Smorgrav , "Ilmar S. Habibulin" , posix1e@cyrus.watson.org, freebsd-security@FreeBSD.ORG Subject: Re: secure deletion In-Reply-To: References: X-Mailer: VM 6.63 under Emacs 19.34.1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org brooks@one-eyed-alien.net writes: > On 21 May 1999, Dag-Erling Smorgrav wrote: > > > "Ilmar S. Habibulin" 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@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message