The trouble with symbolic links

Posted Jul 7, 2022 22:55 UTC (Thu) by Hello71 (guest, #103412)
In reply to: The trouble with symbolic links by developer122
Parent article: The trouble with symbolic links

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 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.