From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 21 05:30:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8F3716A4CE; Fri, 21 Nov 2003 05:30:24 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A81943F75; Fri, 21 Nov 2003 05:30:19 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 0BE115309; Fri, 21 Nov 2003 14:30:18 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 167695308; Fri, 21 Nov 2003 14:30:08 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 9BD0933C86; Fri, 21 Nov 2003 14:30:08 +0100 (CET) To: Pawel Jakub Dawidek References: <20031119003133.18473.qmail@web11404.mail.yahoo.com> <200311201327.29226.wes@softweyr.com> <20031121095939.GS511@garage.freebsd.pl> <20031121124350.GT511@garage.freebsd.pl> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 21 Nov 2003 14:30:08 +0100 In-Reply-To: <20031121124350.GT511@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Fri, 21 Nov 2003 13:43:50 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flood.des.no X-Spam-Level: ss X-Spam-Status: No, hits=2.5 required=5.0 tests=RCVD_IN_DYNABLOCK autolearn=no version=2.60 cc: Rayson Ho cc: phk@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: "secure" file flag? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2003 13:30:25 -0000 Pawel Jakub Dawidek 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. 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. 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. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no