The trouble with symbolic links

Posted Jul 7, 2022 20:27 UTC (Thu) by developer122 (guest, #152928)
Parent article: The trouble with symbolic links

Could this have been avoided if creating a symlink required permissions in both the source and destination directories?

(I suppose this would require a filesystem to be checked and it's symlinks validated/invalidated during mounting)

to post comments

The trouble with symbolic links

Posted Jul 7, 2022 22:55 UTC (Thu) by Hello71 (guest, #103412) [Link] (3 responses)

sure, but also the permissions on the destination and all of its parents can never be changed during the lifetime of the link, implying that for each file and directory, either a list of all links to it and its children must be stored, or whenever its permission is changed, the whole filesystem must be walked.

The trouble with symbolic links

Posted Jul 8, 2022 9:01 UTC (Fri) by taladar (subscriber, #68407) [Link]

Not necessarily. Technically it would be enough to keep a reference counter and only allow permission changes when it is 0. The issue with that would be that it could go out of sync with the actual number of links pointing to the directory in certain situations but that is the same with the list.

The trouble with symbolic links

Posted Jul 8, 2022 21:12 UTC (Fri) by developer122 (guest, #152928) [Link] (1 responses)

That doesn't actually sound like a problem.

If you're giving someone permission to make a simlink in a folder, then why care about any of it's parents? How is it different than regular wread/write access to the folder? (you'd be able to make/change files there anyway) Wouldn't altering/removing a parent break the simlink during lookup?

The trouble with symbolic links

Posted Jul 8, 2022 23:12 UTC (Fri) by developer122 (guest, #152928) [Link]

Thinking about it some more, I suppose you could change the ownership of the containing folder, create *another* symlink to it, and then optionally change the ownership back. Then the file is effectively double-mapped. There might be some way around this by checking the ownership at runtime or some other extra checks or reference counters, but it definitely needs to be considered carefully.

I still don't see what the issue is with altering parent directories of the folder in question though, or what special capability symlinks add to that scenario.