Date: Sun, 14 Mar 1999 12:16:29 -0600 (CST) From: James Wyatt <jwyatt@RWSystems.net> To: The Unicorn <unicorn@blackhats.org> Cc: Robert Watson <robert+freebsd@cyrus.watson.org>, Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.4.05.9903141112050.5759-100000@kasie.rwsystems.net> 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:
> > 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.
To quote Bill The Cat: Ack! Phht!
No! Please, No! I use arg0 in a lot of my programming when it's useful to
have common code that does related, but different, things. (Please look at
the boot disk, vi/ex/view/nvi/nex/nview, gzip/gunzip/zcat/gzcat, gcc/cc,
compress/uncompress, etc...) If you want to find more, just try:
find / -links +1 -type f -print | xargs ls -l | more
This is just too useful to most folks to save the sysadmin who doesn't
read their nightly security mailings. It is also why I like a /tmp filesys
(as well as a /home) filesys on machines with real users. Don't let them
link on drives w/important binaries and don't let them vi ~/bigfile to
fill-up /tmp and hurt everyone using '/'! Ensure, if you have one, that
~ftp/incoming is a separate filesys too. 8{)
> > 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.
Geez, even SCO Xenix tar got this right. Dump can't miss it and cpio gets
it right (even on devs!); so who's tar broke this? (Minix doesn't count 8{)
> 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...
Uh, I know a lot of admins that I consider 'worth their salt' who don't
check link counts (or maybe even notice them in an 'ls -l') before
removing a file. I don't think system upgrade scripts do it either.
> Have a look at ls -l `which vi view ex` and think again about what hard
> links contribute (then again similar functionality might be constructed
> using soft-links; but they are much harder to administrate (read: keep
> under control))
Symlinks do not prevent the original binary from being unavailable. Please
remember that files don't really go away until all links are zero and no
more filedescs are open on them. Hey, if 'the founders' had meant for
symlinks to be used over hard links, there would have been an 'ls -h'
flag, right? 8{)
> Just my 0.02 euro.
This means it's euro-pinion? What's the conversion rate? - Jy@
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.4.05.9903141112050.5759-100000>