In last month's issue, I talked about Linux permissions (see "It's Better to Ask Forgiveness..." in the May 2015 UpFront section). I could have covered SUID, GUID and sticky bit in the same article, but it seemed like a lot to cover in one sitting. So in this article, I describe the special permissions on a Linux system. Where standard permissions are fairly intuitive, the special permissions don't make a lot of sense at first. Once you understand what they do, however, they're really not too complicated.

But There's No Room for More Permissions!

When you learned to set read, write and execute bits on files and folders, you probably realized that you used all the available "spots" for permissions. So when manipulating special permissions, you sort of re-use existing permission bits. It functions just like any other permission attribute, but they're represented a bit oddly.

Every section of the permissions string (user, group, other) has an additional "special" permission bit that can be set just like rwx. The indication for whether those bits are set is shown on the execute section of the string. For example:

• If the SUID (Set User ID) permission is set, the execute bit on the user section shows an s instead of an x.

• If the GUID (Group User ID) permission is set, the execute bit on the group section shows an s instead of an x.

• If the sticky bit is set, the execute bit on the other section shows a t instead of an x.

Confused yet? Here are a few examples:

• -rwsrw-rw- — SUID is set on this file.

• drw-rwsrw- — GUID is set on this folder.

• drw-rw-r-t — sticky bit is set on this folder.

• -rwSr--r-- — SUID is set on this file, but the user execute bit is not.

Note that in the last example the S is uppercase. That's the way you can tell whether the execute bit underneath is set. If the SUID bit is lowercase, it means the execute bit is set. If it's uppercase, it means the SUID bit is set, but the executable bit is not.

What Do They Do?

Unlike standard permissions, special permissions change the way files and folders function, as opposed to controlling access. They also function differently depending on whether they're assigned to files or folders. Let's take a look at them one at a time.

SUID: the SUID bit is applied to executable programs. Once it is set, the program executes with the permissions and abilities of the user who owns the file. As you can imagine, this can be an enormous security risk! If a file is owned by root and has the SUID bit set, anyone who executes it has the same permissions as the root user. As scary as it sounds, there are a few valid use cases for such things. One perfect example is the ping program. In order to access the network hardware required to ping hosts, a user needs to have root access to system. In order for all users to be able to use ping, it's set with the SUID bit, and everyone can execute it with the same system permission that root has. Check it out on your system by typing ls -l /bin/ping. You should see the SUID bit set!

Setting the SUID bit on folders has no effect.

GUID: the GUID set on executable files has a similar effect to SUID, except that instead of using the permissions of the user who owns the file, it executes with the permissions of the group membership. This isn't used very often, but in certain multi-user environments, it might be desirable.

Mainly, GUID is used on a folder. If the GUID bit is set on a folder, files created inside that folder inherit the same group membership of the folder itself. This is particularly useful in group collaborations. Normally when someone creates a file, it has the group membership of that user's primary group. Inside a GUID folder, the user still owns the file, but the group membership is set automatically so others in the group can access the files.

Sticky bit: first off, I have no idea why the sticky bit is represented by a t instead of an s. I've searched high and low, and asked many people. No one seems to know. Maybe a Linux Journal reader knows the answer and will enlighten me. (If so, I'll include it in the Letters to the Editor section.) Anyway, the sticky bit is another special permission that is used on folders. In fact, it has no effect at all if it's set on a file.

Folders that have the sticky bit set add a layer of protection for files created within them. Normally in a folder accessible by multiple people, anyone can delete anyone else's files. (Even if they don't have write access to the files!) With the sticky bit set, only the user who owns the file can delete it. It seems like a subtle thing, but when you consider a folder like the /tmp folder on a multi-user Linux system, you can see how important the sticky bit can be! In fact, if it weren't for the sticky bit, the /tmp folder on your system would be like the Wild Wild West, and nefarious gunslingers could delete other people's files willy nilly. You can see the sticky bit set on your system by typing ls -l / | grep tmp.

Assigning Special Permissions

Applying the special permissions to a file or folder is exactly like assigning regular permissions. You use the chmod tool—for example:

• chmod u+s file.txt — adds the SUID permission to file.txt.

• chmod g-s file.txt — removes the GUID permission from file.txt.

• chmod o+t folder — adds the sticky bit to the "folder" directory.

Special permissions can be assigned right alongside regular permissions as well, so things like this are perfectly fine:

chmod ug+rw,u+s,ugo-x file.txt

And just like standard permissions, it's possible (and often preferable) to assign special permissions using octal notation. In order to do that, you use the fourth field. When assigning permissions like this:

chmod 755 file.txt

there's a fourth field that if left off, is assumed to be zero. So this is actually the same as the above example:

chmod 0755 file.txt

That preceding zero is the field that assigns special permissions. If you leave it off, it's assumed to be zero, and no special permissions are assigned. Knowing it's there, however, should make it fairly easy to understand how to use it. If you read last month's article on permissions that included understanding octal notation, just apply that concept to special permissions. Figure 1 shows how it breaks down.

Figure 1. Octal Notation

So in order to assign a folder read/write access for user and groups along with the GUID bit, you would type:

chmod 2770 foldername

And, the resulting permission string (seen by typing ls -l) would show the following (note the lowercase s— remember what that means?):

drwxrws--- foldername 

Just like standard permissions, if you want to set multiple special permissions, you just add the values. In order to set SUID and sticky bit, you would set the fourth octal field to 5. Usually, only a single special permission is set on any particular file or folder, but with octal notation, you have the option to set them in any way you see fit.

Hopefully these two articles clear up any misconceptions about Linux permissions. More complicated access controls are available with ACLs, but for most use cases, the standard permission strings are all you need to control access to files and folders on your system.