From owner-freebsd-security Thu May 20 8:53:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from india.wind-river.com (india.wind-river.com [12.10.173.8]) by hub.freebsd.org (Postfix) with ESMTP id A77FA14D04 for ; Thu, 20 May 1999 08:53:38 -0700 (PDT) (envelope-from jmaslak@wind-river.com) Received: from junk (jerico-sv-12.wind-river.com [12.10.173.1]) by india.wind-river.com (8.9.3/8.9.3) with SMTP id KAA19259 for ; Thu, 20 May 1999 10:02:08 -0600 Message-Id: <3.0.6.32.19990520095507.00840010@india.wind-river.com> X-Sender: jmaslak@india.wind-river.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 20 May 1999 09:55:07 -0600 To: security@freebsd.org From: Joel Maslak Subject: Secure Deletion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Let's keep standard BSD semantics here, please! As for "secure" deletion... Why doesn't someone just write a simple user-space program to do that. True, it wouldn't handle calls to unlink(), but one would think that someone could modify the library really quick (provided no one does a system call directly, but uses the libc interface instead). I think this would be much better for everyone involved. Some problems with my idea... Static-linked executables would need to be recompiled Library would need to be modified on "secure" systems If all you want is a way to force a file to go away from the command line, just rewrite rm. Joel Maslak UPDATE -- Generate Web Traffic http://www.permission-marketing.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message