Is chmod behavior wrong for symlinks

chmodsudosymlink

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?

Best Answer

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.

Related Question