Symbolic Link Permissions – Why chmod Doesn’t Change Them

chmodpermissionssymlink

I have access to a remote Linux machine where every time I create a symbolic link, it is created by default with the following permissions: lrwxrwxrwx

If I try to change the permissions of the symbolic link (i.e. not the path that it points to) using for example:

chmod g-w my_symbolic_link

chmod runs correctly (no error message is printed) but when I check the permissions again, they are still the same (lrwxrwxrwx).

I am waiting to hear from the machine administrator, but I was wondering if this is normal behavior, or if it is something specific to the box.

Best Answer

It's normal behavior. What happens can vary depending on the operating system (Solaris at least used to change the link permissions); but since a symlink isn't a normal file, the permissions don't actually get used for anything. (File permissions are part of the file's inode, so the symlink can't affect them.)

Related Solutions

Symlink – How to Change Permissions for a Symbolic Link

You can make a new symlink and move it to the location of the old link.

ln -s <new_location> npm2
mv -f npm2 npm

That will preserve the link ownership. Alternatively, you can use chown to set the link's ownership manually.

chown -h myuser:myuser npm

On most systems, symlink permissions don't matter. When using the symlink, the permissions of the components of symlink's target will be checked. However, on some systems they do matter. MacOS requires read permission on the link for readlink, and NetBSD's symperm mount option forces link permissions checks on read and traversal. On those systems (and their relatives, including FreeBSD and OpenBSD) there is a equivalent -h option to chmod.

chmod -h 777 npm

Chmod does not change permissions of certain directories

If you want to grant global write permission on that directory, you have to do

chmod a+w wp.localhost [1]

This is because omitting the 'who is affected' letter (u, g, o or a) implies a, but won't set bits that are set in your current umask. So, for example, if your umask was 0022, the 'write' bit is set in the 'group' and 'other' positions, and chmod will ignore it if you don't specify a explicitly.

The chmod man page is explicit about this:

If none of these ['who is affected' letters] are given, the effect is as if a were given, but bits that are set in the umask are not affected.

[1] Think carefully before doing this!

Best Answer

Related Solutions

Symlink – How to Change Permissions for a Symbolic Link

Chmod does not change permissions of certain directories

Related Question