Search code examples
shellln

Symbolic link not inheriting permissions

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?

Solution

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