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.
