Is chmod behavior wrong for symlinks?

Question

Recently we had a problem on a Red Hat Linux box with many users: the /usr/bin/sudo binary has lost its sticky bit. Work was blocked until root user fix it (we need sudo for deploying and testing).

The reason of this breakdown was... symlink $HOME/bin/s pointing to /usr/bin/sudo. I thought that having one more bash alias is not good and symlink is a simpler solution that will work with any shell, so I have created symlink $HOME/bin/s pointing to /usr/bin/sudo. Then a guy copied my $HOME/bin to his $HOME and "just in case" called sudo chmod 755 $HOME/bin/*. As result /usr/bin/sudo have got 0755 permissions instead of needed 4111. Now it's fixed, root has logged in and restored permissions for sudo.

man chmod (Red Hat, Ubuntu):

  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  sym-
  bolic link listed on the command line, chmod changes the permissions of
  the pointed-to file.

My question is: was it my fault because I should never create symlinks pointing to binaries OR is chmod behavior wrong and it shouldn't change permissions of files pointed by symlinks? Why is this the behavior of chmod? Does it make any sense?

Answer 1

Making symlinks to binaries is fine; check /bin and /usr/bin and you'll almost certainly find a number of aliases. The problem here is using sudo without fully understanding the consequences. Fortunately there was no permanent harm and you learned an important lesson. When you're just making sure they're executable, use a+x or even u+x instead. As uther says, you'd probably be better off with an alias anyway.

The man page itself explains why this is the action -- the permissions on symlinks don't matter, only on the files they resolve to. More often than not, the user does want to change the attributes of the file the link points to.

Also, I just checked the chmod() syscall man pages for Linux and BSD. They both return errors for symbolic link loops, implying that this behavior of changing the file's perms and not the link's is determined and enforced at the kernel level.

Answer 2

I agree it doesn't make a lot of sense if you think of a symlink as a symlink.

But if you think of a symlink as being like a hard link it makes more sense.

The first line of man 7 symlink says exactly this

Symbolic links are files that act as pointers to other files. 
To understand their behavior, you must first understand how hard links work.

A hard link to a file is indistinguishable from the original file because
it is a reference to the object underlying the original filename.
[...]
Changes to a file are independent of the name used to reference the file. 

So, with a hard link, when you change the permissions on the file via any name, the underlying permissions are changed for all names.

Most tools try to follow symlinks, so that you can pretend that it's really a hard link.

Except as noted below, commands follow symbolic links named as
command-line arguments.

The mv(1) and rm(1) commands do not follow symbolic links named as
arguments, but respectively attempt to rename and delete them. 

Commands traversing a file tree [...]

Creating symlinks (or hard links) to binaries is sometimes useful, but as you just discovered, it does create some corner cases that could cause problems.

That said, I think the bigger problem here was using sudo when it was not needed.

If the other user was supposed to have read access to your ~/bin, then sudo was completely unnecessary.

Or if they didn't have access, you could have granted it (e.g. using chmod g+rx $HOME/bin), or provided them with a tarball.

If you still think using sudo is a good idea, here's a few alternatives:

sudo chown -h $USER $HOME/bin/*
chmod 755 $HOME/bin/*

-h tells chown to not follow the symlinks

chmod -R 755 $HOME/bin/*

-R tells chmod to "traverse the file tree", which makes it ignore symlinks as hinted at above in man 7 symlink.

sudo find $HOME/bin/ -type f -exec chmod 755 {} +

-type f tells find to not run the exec command (in this case chmod) on symlinks.

# as user 2
cd ~user2/bin
sudo tar -C ~user1/bin -cf - . | tar -xf -

runs the tar -cf as root so you can see any files, but runs tar -xf as user2, which causes the extracted files to be owned by user2.

Answer 3

Mikel already said it, but it's kind of buried in his answer, so: the real thing that was done wrong is

sudo chmod 755 $HOME/bin/*     # <<<< highly suspicious!

It is rather bizarre to need superuser permissions to act on files in one's home directory. If the guy found that he didn't have the permissions to do something in his own home directory, he should have investigated the situation, and not blindly run sudo. To reiterate: do not blindly run sudo. If the guy had ran chmod 755 $HOME/bin/*, then he would have seen the error message chmod: changing permissions of/home/guy/bin/s': Operation not permitted`.

By the way, I do not recommend making s an alias for sudo (and if you must do it, I recommend that you use a shell alias and not a symbolic link: there is no point in this name being available to scripts). sudo is not benign operation, you can afford to type three extra characters when you run it. Giving it a one-character alias increases the risks of typos.

It is a little surprising that chmod acts on the target of symbolic links, when most operations on metadata act on the link itself. However, symbolic links have no useful permissions: they are never written (only created and overwritten) or executed, and there is rarely any point to hiding their target. Unix variants differ as to whether chmod affects symbolic links (not supported by all systems), their target, or neither. On Linux, chmod affects the target.

Answer 4

Making an alias and making a symlink to a file are both valid (though aliases are generally preferred). I don't think there is a "fault" in this situation. This is the behavior of chmod, so now you know how chmod works on symlinked files (it hasn't changed) and can avoid doing this in the future. If it does happen again, you know how to fix it.