From owner-freebsd-security Sat Mar 13 23:54: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.enteract.com (thor.enteract.com [207.229.143.11]) by hub.freebsd.org (Postfix) with SMTP id 0A08C14E30 for ; Sat, 13 Mar 1999 23:54:02 -0800 (PST) (envelope-from dscheidt@enteract.com) Received: (qmail 24182 invoked from network); 14 Mar 1999 07:53:44 -0000 Received: from nathan.enteract.com (dscheidt@207.229.143.6) by thor.enteract.com with SMTP; 14 Mar 1999 07:53:44 -0000 Date: Sun, 14 Mar 1999 01:53:43 -0600 (CST) From: David Scheidt To: The Unicorn Cc: freebsd-security@FreeBSD.ORG Subject: Re: ACLs 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: :> 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. : :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... : You have to remeber to check, though. I don't look at the link count every time before I a rm a file. There are all sorts of people admining boxes who haven't sense to check for this. I suspect there are lots of otherwise competent people who don't even know to look for this. Removing the problem might be a better solution than trying to educate the world about it. :As far as I am aware there are backup utilities that DO preserve hard :links (if I am not mistaken GNU tar does). GNU tar does this, at least in modern versions. It may not have since the begining of time. Dump preserves this as well. : :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)) Programs which do different things depending on the name they are invoked under is not a feature. :Just my 0.02 euro. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message