From owner-freebsd-security Sun Mar 14 9:19:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (Postfix) with ESMTP id 09122151D4 for ; Sun, 14 Mar 1999 09:19:42 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id MAA05252; Sun, 14 Mar 1999 12:16:48 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Sun, 14 Mar 1999 12:16:47 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: The Unicorn Cc: Thomas Valentino Crimi , freebsd-security@FreeBSD.ORG Subject: Re: ACL's In-Reply-To: <19990314081933.A438@unicorn.quux.org> 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 Sun, 14 Mar 1999, The Unicorn wrote: > On Sat, Mar 13, 1999 at 07:26:52PM -0500, Robert Watson wrote: > > On Sat, 13 Mar 1999, Thomas Valentino Crimi wrote: > > > > [ POSIX related stuff deleted... ] > > > BTW, I'd really like to get rid of hard links -- they allow users to > > retain copies of setuid files after the owner thinks they are deleted. > > I.e., user creates a hard link to /usr/sbin/somesetuidbin to > > /usr/tmp/mytemp. Now the admin upgrades the machine, thinking they have > > removed the risk of the now known buggy somesetuidbin. > > > > Also, since directory permissions act as a cumlative masks on the > > permissions of files held in them, it can be hard to revoke access to a > > file you own--someone else may have hard linked it elsewhere in the fs > > without your knowledge (something they can do as long as they own the > > target directory). Given that hard links already cause inconsistent > > semantics in the name space for users, and aren't properly preserved in > > tar, etc, I think they don't contribute much. > > They cause inconsistent semantics, but they are recorded in the inode as > the number of links to the file the inode holds information on. Therefor > any admin who is worth the money they receive for doing their task will > know that if the number of links to a file is greater than one another > hard link must exist. Searching the filesystem for another name > referring the same inode is then not a really hard thing to do... Race conditions? There is guarantee that between your stat() and unlink() no one else can do an link(). Same goes for searching. The same response applies in my mind to the prevent-linking-of-setuid suggestion -- if you do an atomic open() with O_CREAT and O_EXCL, and specify the correct mode at creation, you can indeed manage this correctly. But many utilities become setuid by virtue of the chmod user command, allowing for a race wherein the file is created, linked, and then chmod'd. I concede the point on GNU tar -- it indeed appears to handle hard links on files correctly. However, I still argue that the ability to sometimes ln and sometimes not ln is probably not consistent. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message