It seems that Linux supports changing the owner of a symbolic link (i.e. lchown) but changing the mode/permission of a symbolic link (i.e. lchmod) is not supported. As far as I can see this is in accordance with POSIX. However, I do not understand why one would support either one of these operations but not both. What is the motivation behind this?
2 Answers
Linux, like most Unix-like systems (Apple OS/X being one of the rare exceptions), ignores permissions on symlinks when it comes to resolving their targets for instance.
However ownership of symlinks, like other files, is relevant when it comes to the permission to rename or unlink their entries in directories that have the t bit set, such as /tmp.
To be able to remove or rename a file (symlink or not) in /tmp, you need to be the owner of the file. That's one reason one might want to change the ownership of a symlink (to grant or remove permission to unlink/rename it).
$ ln -s / /tmp/x $ rm /tmp/x # OK removed $ ln -s / /tmp/x $ sudo chown -h nobody /tmp/x $ rm /tmp/x rm: cannot remove ‘/tmp/x’: Operation not permitted Also, as mentioned by Mark Plotnick in his now deleted answer, backup and archive applications need lchown() to restore symlinks to their original owners. Another option would be to switch euid and egid before creating the symlink, but that would not be efficient and complicate right managements on the directory the symlink is extracted in.
answered Aug 26, 2015 at 13:45
Stéphane Chazelas
586k96 gold badges1.1k silver badges1.7k bronze badges
- I am not sure whether this is the original motivation, but it does give a reason why the design is useful. Thanks!Florian Brucker– Florian Brucker2015-09-03 00:04:52 +00:00Commented Sep 3, 2015 at 0:04
There is no lchmod() in posix but fchmodat() that would allow to set the permissions of a symlink. This still does not require the permissions of symlinks to be evaluated.
- 1OP knows not having
lchmodis in accordance with POSIX. What does this answer add that is not already in the question?muru– muru2015-08-25 22:22:09 +00:00Commented Aug 25, 2015 at 22:22 - The op asked why only one of the functions is supported and I explained that virtually both are available, just not under the name mentioned.schily– schily2015-08-25 23:01:32 +00:00Commented Aug 25, 2015 at 23:01
- 1How so? The standard says: Some implementations might allow changing the mode of symbolic links. This is not supported by the interfaces in the POSIX specification. Systems with such support provide an interface named lchmod(). To support such implementations fchmodat() has a flag parameter. All this says is there's a flag for fchmodat that lets the implementation change symlink perms. Not that it necessarily can.muru– muru2015-08-25 23:04:58 +00:00Commented Aug 25, 2015 at 23:04
- Correct, as permissions of symlinks are not evaluated since 35 years, it makes no sense to change the modes. Fchmodat() exists for orthogonslity. The only real advantage was futimensat() as settable timestamps for symlinks help humans to understand a directory tree.schily– schily2015-08-26 09:17:40 +00:00Commented Aug 26, 2015 at 9:17
- @schilly, OS/X does honour permissions on symlinks. There, if you don't have read permissions, you can't resolve their targets.Stéphane Chazelas– Stéphane Chazelas2015-08-26 16:11:01 +00:00Commented Aug 26, 2015 at 16:11
lrwxrwxrwx. Achmodmakes no sense here. Following the link leads you to the targets permissions.lchmod. But other Unix-like OS do support it (e.g. Mac OS X), so the question is why Linux doesn't when it does supportlchown.