12

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?

Florian Brucker
  • 875
  • 1
    The permissions of a symlink are always lrwxrwxrwx. A chmod makes no sense here. Following the link leads you to the targets permissions. – ott-- Aug 23 '15 at 19:36
  • 2
    @ott: On Linux, a symlink's permissions are always the ones you gave precisely because Linux does not support 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 support lchown. – Florian Brucker Aug 24 '15 at 05:58

2 Answers2

11

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.

Community
  • 1
Stéphane Chazelas
  • 544,893
0

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.

schily
  • 19,173
  • 1
    OP knows not having lchmod is in accordance with POSIX. What does this answer add that is not already in the question? – muru Aug 25 '15 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 Aug 25 '15 at 23:01
  • 1
    How 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 Aug 25 '15 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 Aug 26 '15 at 09: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 Aug 26 '15 at 16:11
  • HP-UX permits to have symlink permissions other than 777 but the permissions are not evaluated. – schily Aug 26 '15 at 20:58