Set and Then Clear sgid

Set and Then Clear sgid

chmod g[+-]s

Closely related to suid is sgid. sgid can apply to both files and directories. For files, sgid is just like suid, except that a user can now execute a file with the group's permissions instead of an owner's permissions. For example, on your system the crontab command is probably set as sgid, so that users can ask cron to run programs for them, but as the much more restricted crontab group rather than the all-powerful root user.

$ ls -l /usr/bin/crontab -rwxr-sr-x 1 root crontab ... /usr/bin/crontab 

When applied to directories, sgid does something interesting: Any subsequent files created in that directory belong to the group assigned to the directory. An example helps make this clearer.

Let's say you have three usersAlice, Bob, and Carolwho are all members of the admins group. Alice's username is alice, and her primary group is also alice, an extremely common occurrence on most Linux systems. Bob and Carol follow the same pattern, with their usernames and primary groups being, respectively, bob and carol. If Alice creates a file in a directory shared by the admins group, the owner and group for that file is alice, which means that the other members of the admins group are unable to write to that file. Sure, Alice could run chgrp admins document (or chown :admins document) after she creates a new file, but that quickly grows incredibly tedious.

If the shared directory is set to sgid, however, any new file created in that directory is still owned by the user who created the file, but it's also automatically assigned to the directory's group, in this case, admins. The result: Alice, Bob, and Carol can all read and edit any files created in that shared directory, with a minimum of tedium.

Unsurprisingly, you can set sgid with either letters or numbers. Using letters, sgid is just like suid, except that a g instead of a u is used. Let's look at sgid applied to a directory, but keep in mind that the same process is used on a file.

$ ls -lF drwxr-xr-x 11 scott admins ... bin/ $ chmod g+s bin $ ls -lF drwxr-Sr-x 11 scott admins ... bin/ 

Note

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

Removing sgid is pretty much the opposite of adding it.

$ ls -lF drwxr-Sr-x 11 scott admins ... bin/ $ chmod g-s bin $ ls -lF drwxr-xr-x 11 scott admins ... bin/ 

If you haven't already read the previous section, "Set and Then Clear suid," go back and do so, as it explains the otherwise mysterious fourth digit that appears just before the number representing the owner's permissions. In the case of suid, that number is 4; for sgid, it's 2.

$ ls -lF drwxr-xr-x 11 scott admins ... bin/ $ chmod 2755 bin $ ls -lF drwxr-Sr-x 11 scott admins ... bin/ 

You remove sgid the same way you remove suid: with a 0 at the beginning, which takes sgid out of the picture.

$ ls -lF drwxr-Sr-x 11 scott admins ... bin/ $ chmod 0755 bin $ ls -lF drwxr-xr-x 11 scott admins ... bin/ 

Note

You know what creating a new file in a sgid directory will do, but be aware that other file system processes can also be affected by sgid. If you copy a file with cp into the sgid directory, it acquires the group of that directory. If you move a file with mv into the sgid directory, however, it keeps its current group ownership and does not acquire that of the directory's group. Finally, if you create a new directory inside the sgid directory using mkdir, it not only inherits the group that owns the sgid directory, but also becomes sgid itself.