Date: Sun, 14 Mar 1999 21:58:23 -0600 (CST) From: James Wyatt <jwyatt@RWSystems.net> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Jon Hamilton <hamilton@pobox.com>, Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>, freebsd-security@FreeBSD.ORG Subject: Re: ACL's Message-ID: <Pine.BSF.4.05.9903142140111.5759-100000@kasie.rwsystems.net> In-Reply-To: <Pine.BSF.3.96.990314152855.5121H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Mar 1999, Robert Watson wrote:
> point of view of the user. Symlinks have consistent behavior across the
> entire namespace, and leaving aside the garbage collection issue, provide
> pretty much all functionality hardlinks do.
I think we seriously disagree on 'pretty much'. Maybe on 'consistent'.
> This garbage-collection issue is in fact the change that I want: the names
> referencing an object should obey the semantics required by the controller
> of the original object, not of anyone who is able to read it at any point
> in its history. Symlinks allow me to revoke access to an object
> trivially, and consistently with the hierarchal directory behavior. And
> since files in UNIX convey capabilities, this is actually extremely
> important.
Anyone who was able to hard link to it, not just read it. 'chmod 0 file'
works orthogonally w.r.t. hard and symbolic links. So does 'cp /dev/null'
for those rare times you *have* to be sure. Symlinks allow the original
file to 1) disappear and 2) 'look' accessable at first glance.
> In response to the absolute symlink concern: this is why in my example
> (see some email or another) I used only relative symlinks. You'll find
> that, given the arbitrary way partitioning occurs, this is the only useful
> way to manage hard links also: the user can specify any
> directory-separated partioning scheme they choose when they install, and
> most of them make sense.
Is there a difference between an absolute and relative hard link?
> Removing hard links helps us in a number of ways: it allows for a unique
> name relative to a partition for a file (great for auditing and TPE); it
> allows atomicity and reliability for deletion, along with prevention of
> inode hijacking. It provides a more consistent view of the FS to the
> average user: symlinks work across partitions, network file systems, etc.
> It allows a unique set of permissions to be evaluated for a file, ensuring
> that a common set are applied to all users. It allows revocation of file
> access to be ensured by the owner.
Ref counts are great for auditing as well, but symlinks don't have
them. We've had some suprises with symlinks on NFS. As every symlink I've
ever seen has 777 permissions, I have to look (maybe several symlinks
deep!) for the original file. If I 'chmod 0' any of a hard link, all of
them instantly and directly show the modifications. It's ensured as well.
> As with all aliasing, symlinks can result in surprises. I argue that they
> result in fewer surprises; in particular, fewer security-related
> surprises.
I'll argue not many fewer, in practice, but I hope we're winding down. 8{)
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.9903142140111.5759-100000>