The trouble with symbolic links

Posted Jul 7, 2022 17:54 UTC (Thu) by jthill (subscriber, #56558)
In reply to: The trouble with symbolic links by khim
Parent article: The trouble with symbolic links

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.

to post comments

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.