Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Mar 1999 12:16:47 -0500 (EST)
From:      Robert Watson <robert@cyrus.watson.org>
To:        The Unicorn <unicorn@blackhats.org>
Cc:        Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu>, freebsd-security@FreeBSD.ORG
Subject:   Re: ACL's
Message-ID:  <Pine.BSF.3.96.990314120529.5121B-100000@fledge.watson.org>
In-Reply-To: <19990314081933.A438@unicorn.quux.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990314120529.5121B-100000>