The long road to a fix for CVE-2021-20316

An alternative approach that breaks much less, probably nothing, while retaining the security benefits of root-only symlinks: non-root-owned symlinks (or, more generally, symlinks with uids not specified in a new file under /proc/sys somewhere: root only by default) are only followed by the user that owns them: other users get the effect of O_NOFOLLOW on that symlink without needing to ask for it.

Now hostile users can create all the symlinks they want, as can non-hostile users, and the use case the non-hostile users wanted still works (they can follow symlinks they created, and symlinks the sysadmin or package installer created), while the hostile users find that they are following the hostile symlinks they created, but nobody else is. This obviously should apply at all stages in path resolution, including if a path contains a symlink to a directory. (I don't think we need to worry about races involving symlink ownership suddenly changing, since only root can do that and if root is malicious you've already lost.)

Anyone still broken by this is probably using gid-shared directories for something, like it was the 1980s still. They're probably using ACLs too. A slightly more permissive mode, off by default or on only in directories with the setgid bit active or perhaps which are gid-writable, could apply the same check based on the gid of the symlink instead of the uid, which would fix this use case too. I'm sceptical this use case is common enough to worry about, though.

But symlink following in the specific case of following symlinks the admin made and symlinks the user themselves made is so useful that it simply shouldn't be broken. It's not some program's decision to not let me stitch things together with symlinks I created: it's mine, and programs should always follow them. Symlinks a random hostile user created, though -- why would I ever want to follow those? And thankfully file ownership tracks this perfectly well so we can always get the answer right :)