Set and Then Clear suid

Set and Then Clear suid

chmod u[+-]s

In the "Understand the Basics of Permissions" section, you looked at several possible permissions. You've focused on r, w, and x because those are the most common, but others can come in handy at times. Let's take a look at suid, which only applies to executable files, never directories.

After suid is set, suid means that a user can execute a file with the owner's permissions, as though it was the owner of the program running it. You can see a common example of suid in action by looking at the permissions for the passwd command, which allows users to set and change their passwords.

$ ls -l /usr/bin/passwd -rwsr-xr-x 1 root root ... /usr/bin/passwd 

You can see that passwd is set as suid because it has an s where the user's x should be. The root user owns passwd, but it's necessary that ordinary users be allowed to run the command, or they wouldn't be able to change their passwords on their own. To make the passwd command executable for everyone, x is set for the user, the group, and all users on the system. That's not enough, however. The answer is to set passwd as suid root, so anyone can run it with root's permissions for that command.

Note

You might see both an s and an S to indicate that suid is set. You see an s if the owner already had execute permissions (x) before you set suid, and an S if the owner didn't have execute set before suid was put in place. The end result is the same, but the capitalization tells you what was in place originally.

You can set and unset suid in two ways: using the alphabet or using numbers. The alphabet method would look like this:

$ pwd /home/scott/bin $ ls -l -rwxr-xr-- 1 scott admins ... backup_data $ chmod u+s backup_data $ ls -l -rwsr-xr-- 1 scott admins ... backup_data 

Now anyone in the admins group can run the backup_data script as though they were the user scott. But note that anyone not in the admins group is shut out because it only has read permission for the program. If it was necessary for everyone on the system to be able to run backup_data as scott, the permissions would be -rwsr-xr-x.

Removing suid is a matter of using u- instead of u+.

$ ls -l -rwsr-xr-- 1 scott admins ... backup_data $ chmod u-s backup_data $ ls -l -rwxr-xr-- 1 scott admins ... backup_data 

Setting suid via octal permissions is a bit more complicated, only because it introduces a new facet to the numeric permissions you've been using. You'll recall that numeric permissions use three digits, with the first representing what is allowed for the owner, the second for the group, and the third for all other users. It turns out that there's actually a fourth digit that appears to the left of the owner's number. That digit is a 0 the vast majority of the time, however, so it's not necessary to display or use it. In other words, chmod 644 libby.jpg and chmod 0644 libby.jpg are exactly the same thing. You only need that fourth digit when you want to change suid (or sgid or the sticky bit, as you'll see in the following sections).

The number for setting suid is 4, so you'd change backup_data using numbers like this:

$ pwd /home/scott/bin $ ls -l -rwxr-xr-- 1 scott admins ... backup_data $ chmod 4754 backup_data $ ls -l -rwsr-xr-- 1 scott admins ... backup_data 

Removing suid is a matter of purposely invoking the 0 because that sets things back to the default state, without suid in place.

$ ls -l -rwsr-xr-- 1 scott admins ... backup_data $ chmod 0754 backup_data $ ls -l -rwxr-xr-- 1 scott admins ... backup_data 

Note

As an ordinary user, it's not very likely that you'll need to change programs to suid. Most often it's associated with programs owned by root, but it's still good to know about it for that every-so-often case in which you need to use it.