Finding symlink information in MAC Framework

[Robert N. M. Watson]

On 27 Jul 2011, at 16:57, perryh at pluto.rain.com wrote:

> s <s at samu.pl> wrote:
> 
>> ... 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 ...
> 
> 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