How do file permissions apply to symlinks?

Question

Let's say you have this structure:

+ directory
-- file1
-- file2
-- file3 -> /tmp/file3

file3 is a link to another file3 somewhere else on the system.

Now let's say I chmod 777 the directory and all contents inside it. Does my file3 in /tmp receive those permissions? Also, let's say we have the same situation but reversed.

/tmp/file3 -> /directory/file3

If I apply the permissions on the file being linked to, how does that effect the link?

Solution 1

It depends on how you call chmod and the platform you are running on.

For example, on a Linux system, man chmod says this:

chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. However, for each symbolic link listed on the command line, chmod changes the permissions of the pointed-to file. In contrast, chmod ignores symbolic links encountered during recursive directory traversals.

However, on a Mac, chmod can be used to modify the permissions of a symbolic link using options such as this (from man chmod):

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

For the sake of example, lets assume you are on a Linux machine for the rest of this answer.

If in the first case you run chmod -R 777 directory to recursively change the permissions, the link target will not be affected, but if you do chmod 777 directory/*, it will.

If you change the permissions on the link target directly, those permissions will carry through (since as man page and baraboom say, the actual link permissions aren't used for anything).

---

Test log for illustration:

$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3
$ ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file1
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod -R 777 dir && ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file1
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod 700 dir/* && ls -l dir/* /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file1
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

Solution 2

baraboom's and peth's answers are both correct: Permission bits on the symbolic links themselves are irrelevant (except on macOS; see below), and changing permission on a symbolic link – by the chmod command-line tool or by the chmod() system call – will simply act as if it was performed against the target of the symbolic link.

To quote the SUSv4/POSIX.1-2008 description of symlink() system call:

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.

Here, “unspecified” leaves room of interpretation for each implementation. Specifics:

• On Linux (tested using ext4fs), stat() returns st_mode=0777, no matter what the umask was when the symlink was created; ls -l therefore always displays lrwxrwxrwx for symbolic links.
• On macOS (HFS) and FreeBSD (both UFS and ZFS), a symbolic link does have its own permission: The chmod -h command noted above can change this link permission (which internally uses a non-POSIX lchown() system call to achieve this), and the stat() system call returns this value for st_mode.

Symbolic links on Linux and FreeBSD can always be followed, as specified by POSIX. In particular, on FreeBSD, this means that the file mode of a symbolic link has no effect at all on access control.

On the other hand, macOS slightly breaks POSIX. Although a symbolic link can be followed regardless its read permission, readlink() fails with EACCES (Permission denied) if the user does not have read permission:

$ sudo ln -shf target symlink
$ sudo chmod -h 444 symlink
$ ls -l symlink
lr--r--r--  1 root  staff  1 Mar 14 13:05 symlink -> target
$ sudo chmod -h 000 symlink
$ ls -l symlink

ls: symlink: Permission denied
l---------  1 root  staff  1 Mar 14 13:05 symlink
$ echo kthxbye > target
$ cat symlink
kthxbye

(Note that the -> target portion is missing in the output from the second ls -l command, and that cat symlink still succeeded and printed the contents of the target file even though the user did not have read permission on symlink.)

NetBSD apparently offers a special mount option named symperm which, if set, causes symbolic link read/execute permissions to control readlink() and link traversal.

Comments

[Jailton Silva]

Permissions only affect the file, not the symlink.

[Admin]

N.B. above comment does not quite apply to macOS, see answer from @astralblue below for the surprising behaviour there

[jww]

How does this answer the question?

[Edward Falk]

That was a surprise to me too. Next question: who do the permissions on a symlink mean?

[Walf]

@EdwardFalk symlink permissions are not non-restrictive since everything needs to be able to traverse it to get the permissions from the linked file.

[Admin]

Double +1 for exposing this very surprising symlink permission behaviour on macOS -- had to confirm this for myself just now: on a symlink with restrictive permissions, the user cannot resolve the symlink, but can still use it to read and write to the target file!