Date: Sun, 14 Mar 1999 08:19:33 +0100 From: The Unicorn <unicorn@blackhats.org> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Thomas Valentino Crimi <tcrimi+@andrew.cmu.edu>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <19990314081933.A438@unicorn.quux.org> In-Reply-To: <Pine.BSF.3.96.990313192214.2563A-100000@fledge.watson.org>; from Robert Watson on Sat, Mar 13, 1999 at 07:26:52PM -0500 References: <wque1H200Uw_0CHFc0@andrew.cmu.edu> <Pine.BSF.3.96.990313192214.2563A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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...
As far as I am aware there are backup utilities that DO preserve hard
links (if I am not mistaken GNU tar does).
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))
Just my 0.02 euro.
> Robert N Watson
---end quoted text---
Ciao,
Unicorn.
--
======= _ __,;;;/ TimeWaster ================================================
,;( )_, )~\| A Truly Wise Man Never Plays
;; // `--; Leapfrog With A Unicorn...
==='= ;\ = | ==== Youth is Not a Time in Life, It is a State of Mind! =======
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?19990314081933.A438>