From owner-freebsd-security Fri May 21 11: 4:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 6A61215111 for ; Fri, 21 May 1999 11:04:55 -0700 (PDT) (envelope-from brooks@one-eyed-alien.net) Received: from localhost (brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) with ESMTP id LAA11905; Fri, 21 May 1999 11:04:25 -0700 (PDT) From: brooks@one-eyed-alien.net X-Authentication-Warning: orion.ac.hmc.edu: brdavis owned process doing -bs Date: Fri, 21 May 1999 11:04:25 -0700 (PDT) X-Sender: brdavis@orion.ac.hmc.edu To: Dag-Erling Smorgrav Cc: "Ilmar S. Habibulin" , posix1e@cyrus.watson.org, freebsd-security@FreeBSD.ORG Subject: Re: secure deletion In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. -- Brooks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message