Re: cp, ln, mv, install: check for vulnerable target directories

[Paul Eggert]

On 09/21/2017 12:41 PM, Kaz Kylheku (Coreutils) wrote:
> Just like "nodev" doesn't prevent creation of device nodes with mknod,
> but is aimed at curtailing their *use*, the proposed "nolink" mount 
> option
> could similarly prevent the *traversal* of symlinks created in a shared
> directory rather than blocking the means of their creation.

That makes sense, particularly since the filesystem could have been 
created on some other machine and we're just using it; but ...

> Suppose user mallory creates a symlink in a directory where multiple 
> non-root
> users have write access. Then have it so that only mallory can follow the
> symlink (being the owner of the link).
>
> A symlink owned by mallory in a directory that is writable to alice
> shall not be dereferenceable by alice; there will be an EPERM when alice
> tries to traverse it.

I'm not understanding why "is writable to alice" is the correct test 
here. The problem is that the directory is owned by mallory; whether 
alice can write to the directory is irrelevant. After all, if mallory 
owns the directory, mallory can change its permissions at any time.

One other thing. We need to preserve the distinction between a symlink S 
found as part of a longer filename S/T and a symlink S that is the 
entire filename. The proposed change to cp etc. is only about the 
latter, as is the Linux /proc/sys/fs/protected_symlinks approach. We 
don't address the former partly because it's a lost cause anyway, for 
other reasons. I assume the nolinks mount option would also only be 
about the latter; at any rate, this should be made clear.

Regardless of what is done to the mount options, we should fix coreutils 
as well, as we can't assume the platform will support the new options, 
or the protected_symlinks approach either for that matter.