The trouble with symbolic links

Posted Jul 7, 2022 15:48 UTC (Thu) by iabervon (subscriber, #722)
Parent article: The trouble with symbolic links

I think it would make sense to have the kernel not follow symlinks when doing path-based operations in general, and have user space libraries, when doing things that should possibly be affected by symlinks, call realpath(), validate the result as appropriate for having just been given the path from a possibly-malicious source, and use the result, which will probably be a path that works without the kernel following symlinks (or will fail safely).

I could imagine a C library change that would set the prctl and handle symlinks in user space with realpath() for the traditionally-named path-based functions, and include variants that you use instead if you're going to validate the path at all.

The trouble with symbolic links

Posted Jul 7, 2022 16:23 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

That requires all userspace programs not only to follow symlinks but to do so recursively (since any component of a path may be a symlink), and to do so in a race-free fashion. They also all need to spot loops.

How many of them do you imagine will get *that* right, given how many bugs and races there have been in, say, rm -rf, which you'd think is heavily tested? Oh look, a new set of security holes, probably worse than the last lot.

-- N., very heavy user of symlinks, thank god for Nix (the distro, no relation) making sure that not too many break when entire /usr trees are symlink farms

The trouble with symbolic links

Posted Jul 7, 2022 17:38 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (1 responses)

At least in theory libc could be doing all that. However it would also be much slower and wasteful, because all the caching that the kernel does would be split across multiple userspace programs, and the cache would start cold for every new process.

The trouble with symbolic links

Posted Sep 3, 2022 11:56 UTC (Sat) by nix (subscriber, #2304) [Link]

In theory libc could implement its own cross-process cache using shared memory, like nscd. In practice, the mere thought is painful. This is definitely not userspace's job :)

The trouble with symbolic links

Posted Jul 7, 2022 19:33 UTC (Thu) by iabervon (subscriber, #722) [Link]

I imagine that either all userspace programs will get recursively following symlinks right, or they'll all get it wrong, since I think it would be done in libc and they'd all use the same implementation. For that matter, I think the implementation should probably be a system call that takes a path that may use symlinks and returns a path that doesn't use symlinks, in which case everyone would end up using the correct implementation that the kernel uses.

The only change I can see to outcomes of path-based operations from having separate resolve and operate syscalls would be that, if you rename a symlink over a regular file, a poorly-timed open() could get ELOOP instead of either getting the original file or the target of the symlink. Replacing one symlink with another would be atomic, and any other operation isn't atomic today (that is, you can't replace a directory with a symlink atomically, and you can't replace both a symlink and another file atomically; I guess you might get ELOOP when you could only have gotten ENOENT).

As far as changes to userspace program code, the only one would be that, if you've explicitly called realpath() yourself and validated the result in some way, you'd call realopen() on the string you validated rather than calling open() and getting another round of symlink resolution that might be different.

The trouble with symbolic links

Posted Jul 7, 2022 18:56 UTC (Thu) by bartoc (guest, #124262) [Link]

this is a bad idea. You want to be able to use symlinks to point an unsuspecting application somewhere else. The trouble comes when the unsuspecting app has a higher privilege level than the symlink creator.