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 usingsudo
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, usea+x
or evenu+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.