Symbolic link not inheriting permissions

Question

For example, I have foo.sh with 770 permissions. When I do:

ln -s foo.sh bar.sh

The link bar.sh has 2777 permissions. Why is this? I thought they were meant to be inherited?

Starknaked

Can other users still read the contents of foo.sh? I doubt it. – Bum

The point is that the link doesn't matter. It links, so the original file still retains all the permissions and groups, effectively giving the link the same ones (in terms of functionality). – Bum

Beware of SGID shell scripts. They are less dangerous than SUID shell scripts, but still tend to be dangerous. At the least, a SGID script must be very carefully written. Any SGID or SUID program with public write permission is a disaster; you should immediately change the permissions to 2775 or 2755 or 2555. – Soy

Answer 1

The permissions on a symbolic link are largely immaterial. They are normally 777 as modified by the umask setting.

The POSIX standard for symlink() says:

The values of the file mode bits for the created symbolic link are unspecified. All interfaces specified by POSIX.1-2008 shall behave as if the contents of symbolic links can always be read, except that the value of the file mode bits returned in the st_mode field of the stat structure is unspecified.

POSIX provides an lchown() system call; it does not provide an lchmod() function.

(On my MacOS X 10.7.1, with umask 022, a newly created symlink ends up with 755 permissions; with umask 002, the permissions end up as 775. So, the observation that links are created with 770, 700 etc permissions may be accurate; the permissions settings are still immaterial, and do not affect the usability of the symlink.)

---

Further investigations about symlinks on RHEL 5 and MacOS X

1. On Linux (RHEL 5 for x86_64; kernel 2.6.18-128.el5), I only get to see 777 permissions on a symlink when it is created:

   $ (ls -l xx.pl; umask 777; ln -s xx.pl pqr; ls -l xx.pl pqr)
   -rw-r--r-- 1 jleffler rd 319 2011-09-05 22:10 xx.pl
   lrwxrwxrwx 1 jleffler rd   5 2011-09-21 10:16 pqr -> xx.pl
   -rw-r--r-- 1 jleffler rd 319 2011-09-05 22:10 xx.pl
   $
   

   I ran that in a sub-shell so the umask setting was not permanent.

2. On MacOS X (10.7.1), I get to see variable permissions on a symlink:

   $ (ls -l xxx.sql; umask 777; ln -s xxx.sql pqr; ls -l xxx.sql pqr)
   -rw-r--r--  1 jleffler  staff  1916 Jun  9 17:15 xxx.sql
   
   ls: pqr: Permission denied
   l---------  1 jleffler  staff     7 Sep 21 10:18 pqr
   -rw-r--r--  1 jleffler  staff  1916 Jun  9 17:15 xxx.sql
   $
   

   Note that this is the same command sequence (give or take the file name) linked to.

3. On MacOS X, the chmod command has an option -h to change the permissions on a symlink itself:

   -h If the file is a symbolic link, change the mode of the link itself rather than the file that the link points to.

4. On MacOS X, the permissions on the symlink matter; you can't read the symlink unless you have read permission on the symlink (or you're root). Hence the error in the ls output above. And readlink failed. Etc.

5. On MacOS X, chmod -h 100 pqr (execute) allows me to use the link (cat pqr works) but not to read the link. By contrast, chmod -h 400 pqr allows me to both read the link and use the link. And for completeness, chmod -h 200 pqr allows me to use the link but not to read it. I assume, without having formally tested, the similar rules apply to group and other.

6. On MacOS X, then, it seems that read or write permission on a symlink allows you to use it normally, but execute permission alone means you cannot find where the link points (readlink(2) fails) even though you can access the file (or, presumably, directory) at the other end of the link.

Conclusion (subject to modification):

1. On some versions of Linux, you can only get 777 permission on a symlink.
2. On MacOS X, you can adjust the permissions on a symlink and these affect who can use the symlink.

The MacOS X behaviour is an extension of the behaviour mandated by POSIX - or deviation from the behaviour mandated by POSIX. It complicates life slightly. It means that you have to ensure that anyone who is supposed to use the link has permission to do so. This is normally trivial (umask 022 means that will be the case).

The underlying system call for chown -h on MacOS X is setattrlist(2).

Soy

But there are plenty around (say in lib folders) with 770 / 700 etc – Starknaked

Not immaterial. I have a symlink for ~/.ssh and since the perms are 755 ssh complains about permissions are not restrictive even when the target directory is 700. – Henry

Answer 2

http://en.wikipedia.org/wiki/Symbolic_link

The file system permissions of a symbolic link usually have relevance only to rename or removal operations of the link itself, not to the access modes of the target file which are controlled by the target file's own permissions.

The permissions for the link are just that. What it points to still has its own permissions.

Karlene

There are other reasons I might need to set permissions. Support I was my ~/.ssh or some file therein to be a symbolic link. This would make sense if, for instance, I'm trying to keep that file under version control. Since SSH is very strict about permissions on files, if the "file" is expected to have permission 644, but it's really a symlink, then SSH won't be happy and won't let me log in. Right now, for instance, I'm trying to symlink /etc/ssh/sshd_config so that I can keep it under version control, and this won't work. – Corby

Actually, it turned out it was a different problem. I can symlink sshd_config without any trouble even though the symlink has permissions 777 – Corby

@IsaacBetesh That is probably because SSH uses the stat(2), not lstat(2) to get the permissions. Symlinks are often transparent like that. – Epic