Re: symlinks with permissions

[Jamie Lokier <jamie@shareable.org>]

Casey Schaufler wrote:
> Pavel Machek wrote:
> > The actual permissions of the file are not ignored, but permissions of
> > the containing directory _are_. If there's 666 file in 700 directory,
> > you can reopen it read-write, in violation of directory's 700
> > permissions.
> > 									Pavel
> 
> There is no security violation here. Consider the case where
> the file is unlinked after it is opened. What directory permissions
> would matter in that case?

That's an even worse security violation.

If you have a file opened read-only which is unlinked (and there's no
other file descriptors to it), it is impossible to modify the file
except through this quirk of /proc/NN/fd.  In traditional unix, it is
impossible to modify full stop.  Even root can't write to it.

Paths are in this discussion as an *example* of something that cannot
be done except through /proc/NN/fd.  Paths are not the issue.

As you've noticed, the same security hole occurs for files which have
been unlinked and don't have any path.

The real issue is gaining more access to an open file than you had before.

> Or what about the case where the file
> has a link count of 2, say /a/foo and /b/ish are hard links. If
> /a is 777 and /b is 700 what would your position be regarding
> the file descriptor obtained by opening /b/ish?

It depends on the flag passed to open() when the file descriptor is
obtained.  That's where the pseudo-symlink permission comes from,
which is what Pavel is getting it.

> The path name is an ethereal convenience and once traversed has no
> bearing on the security state of the object.

That's right.  The security state should depend _only_ on the
file open mode, that is O_RDONLY/WRONLY/RDWR/APPEND.

That is more or less what Pavel is saying too, because the
pseudo-symlink permission is calculated from the file open mode
(except for O_APPEND, which is why it shouldn't be done using the
pseudo-symlink permission).  Ignore the path aspect, it's just a distraction.

-- Jamie