Date: Wed, 27 Jul 2011 10:14:11 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: perryh@pluto.rain.com Cc: freebsd-hackers@freebsd.org, s@samu.pl Subject: Re: Finding symlink information in MAC Framework Message-ID: <C6E3323D-8C46-4FB6-8D91-2C2850567361@freebsd.org> In-Reply-To: <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com> References: <c0c76b43d88b48a8b354df409b5167e5@samu.pl> <alpine.BSF.2.00.1107250942340.51541@fledge.watson.org> <cdf7c352c5d4a2edc308a6e1ab7d63c0@samu.pl> <4e303567.2SHj2vERr0n8Op6Q%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Jul 2011, at 16:57, perryh@pluto.rain.com wrote: > s <s@samu.pl> wrote: >=20 >> ... I am trying to compare the owner of the symlink to the owner >> of what the symlink points to ... At first I was trying to check >> wheter some user is trying to create such a symlink ... >=20 > I've always considered the "ownership" and "permissions" of a > symlink to be an artifact of the implementation, rather than > having any real significance. > ... > Because the target of a symlink is (in the general case) not > in the same physical filesystem as the symlink itself, the > symlink has to be stored in its own inode -- and that inode, > like any other, has "ownership" and "permission" fields which > will inevitably contain some pattern of bits -- but it's not > clear to me that anything is gained by assigning a meaning to > those patterns. One valid (but historically "after") reason to have owners on symlinks = is the sticky bit on directories: if you want to usefully authorise = deletions of symbolic links in /tmp, you really want an owner for them. > Getting back to the original problem, suppose you had no mounted > filesystems (other than special cases like devfs or /proc), the > entire logical filesystem tree being stored on a single device, so > that any file on the system could be hard-linked into any directory > on the system. How would you detect that "some user" had created a > _hard_ link to some arbitrary file? Right -- I'm not convinced that the suggested design is really coherent = in an underlying sense -- which is one reason it doesn't lend itself to = implementation. Creating a symlink doesn't involve actual access to the = target object at all, since it's really just an object with a string in = it that might point at something else. There's also no "atomic" moment = during today's lookup has all the information it needs to check the = suggested policy. The closest you could get would be to gather ownership = information at the time of readlink, caching it (perhaps in the process = label), and later checking it at the time of the later operation. = However, as many symlinks can be followed on the way to an underlying = object, it sounds like it would require a stack of owners, each of which = would have to be compared at the end. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C6E3323D-8C46-4FB6-8D91-2C2850567361>