The trouble with symbolic links

Posted Jul 7, 2022 16:07 UTC (Thu) by khim (subscriber, #9252)
In reply to: The trouble with symbolic links by Sesse
Parent article: The trouble with symbolic links

> I believe it's a bit of a stretch to say that “pathnames as a concept are now utterly broken in POSIX” just because userspace cannot verify that a path name is contained within some arbitrary part of the file system.

It's like saying that car without wheels and an engine is not broken. I mean: you can still pull it with enough horses attached thus move people and cargo, right? So it's still usable, kinda.

Similarly here: the only difference between pathname and filename is the fact that pathnames have hierarchy.

Sure, apps which don't need pathnames but are just happy to use them as opaque file identifiers in a flat namespace are not broken with symlinks. But everything else is broken is a sense that Joe Average Developer would write incorrect code 10 times out of 10.

How you can call this “not utterly broken” is beyond me.

> Most applications will not have to care whether there's a directory symlink in the path, even if Samba needs to do its own userspace chroot.

On the contrary: practically any app which deals with file hierarchies (and just with individual files) is broken. Not all such programs lead to security vulnerability because sometimes you have situation “Joe can break Joe's program which s/he can crash directly anyway” which is considered acceptable. But they are broken, nonetheless.

to post comments

The trouble with symbolic links

Posted Jul 7, 2022 16:09 UTC (Thu) by Sesse (subscriber, #53779) [Link] (3 responses)

I guess the disparity here is how many apps you think really needs to care. Most that I use certainly don't. File servers (including Apache) are a notable exception.

The trouble with symbolic links

Posted Jul 8, 2022 8:57 UTC (Fri) by gerdesj (subscriber, #5446) [Link] (2 responses)

"File servers (including Apache) are a notable exception."

That's quite a large notable exception!

The trouble with symbolic links

Posted Jul 9, 2022 0:47 UTC (Sat) by willy (subscriber, #9762) [Link]

If you're NetApp, sure. But if you consider desktop (or phone) usage of Linux, it's a small and uninteresting exception.

The trouble with symbolic links

Posted Jul 23, 2022 0:17 UTC (Sat) by DimeCadmium (subscriber, #157243) [Link]

They're also already large projects in and of themselves. Handling symlinks is still ultimately a very minor portion of the code.

The trouble with symbolic links

Posted Jul 7, 2022 17:01 UTC (Thu) by adobriyan (subscriber, #30858) [Link] (4 responses)

> But everything else is broken is a sense that Joe Average Developer would write incorrect code 10 times out of 10.

What are the requirements for, say, non-broken text editor wrt symlinks?

The trouble with symbolic links

Posted Jul 8, 2022 13:00 UTC (Fri) by ilammy (subscriber, #145312) [Link] (3 responses)

If you open a file in multiple tabs via multiple paths, edits in one of them should reflect in the other, immediately.

If a symlink in the open path has changed while a file is being edited, users might or might not want to be notified about that instead of overwriting some other file.

If there is a symlink loop, search by all files in the project should not hang or print out infinite results.

The trouble with symbolic links

Posted Jul 8, 2022 13:05 UTC (Fri) by Sesse (subscriber, #53779) [Link]

I find this example pretty contrived, but OK: stat() the file and check its inode number. (There's no new TOCTTOU, since editors typically don't keep the file descriptors open anyway.)

The trouble with symbolic links

Posted Jul 8, 2022 20:24 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

The first two cases would also be an issue with hard links. You can't assume that a different path means a different file. And all three are possible with bind mounts, network filesystems, FUSE filesystems, or removable devices without involving symlinks in any way, so you need to handle those cases properly whether or not symlinks are available. For example the third case could be addressed by checking the device and inode numbers for each directory to prevent recursion, and also setting an absolute limit on the depth of the search.

The trouble with symbolic links

Posted Jul 8, 2022 22:26 UTC (Fri) by k8to (guest, #15413) [Link]

This is .. not standard text editor behavior.

The trouble with symbolic links

Posted Jul 7, 2022 17:54 UTC (Thu) by jthill (subscriber, #56558) [Link] (1 responses)

Is the concept of user input utterly broken because little bobby tables is such a hellraiser? I don't think so, I don't see how pointing to all the CVEs for failure to scrub user input is any different than pointing to all the CVEs for failure to scrub paths.

Besides, open and fstat the path's final directory, if getuid() owns it you don't even have to vet whatever real path you'd need to get you there, then either you don't follow final symlinks or you iteratively re-vet what readlinkat() for them gets you; and if when you later decide to rewrite your hosts file the path it's going to isn't a previously-vetted device and inode you'd would be well within reason to just refuse to continue.

Instead of blackholing symlinks a quick little library to implement the operations in terms of those safety checks seems reasonable; things like ssh and samba for which those aren't a enough are distinctly not Joe Average Coder projects. `std::filesystem` should probably operate by default only with getuid()-owned files anyway.

The trouble with symbolic links

Posted Jul 7, 2022 22:39 UTC (Thu) by khim (subscriber, #9252) [Link]

> Is the concept of user input utterly broken because little bobby tables is such a hellraiser?

The concept of injecting user input into a string is utterly broken, yes. That's why we have entirely different API which solves that issue once and for all. We don't have anything similar for pathnames.

> Besides, open and fstat the path's final directory

Have you actually read the article? Even finding the path's final directory is quite non-trivial.

> Instead of blackholing symlinks a quick little library to implement the operations in terms of those safety checks seems reasonable

Make one. Give it to Jeremy and we can make a bet about how many ways it's broken.