Special Permission in Linux

A basic guide about setuid and setgid.

6 min readNov 11, 2021

UNIX permissions define the level and kind of access a user or group has. They are like the first line of defense when it comes to securing the files and directories.

Did you know there are permissions apart from Read, Write and Execute available in Linux and other UNIX based systems?

Apart from “x”, “r”, “w”, there is also “s” that you can set on a user or group using “setuid” and “setgid”.

Wikipedia says:

The Unix access rights flags setuid and setgid (short for “set user ID” and “set group ID”) allow users to run an executable with the file system permissions of the executable’s owner or group respectively and to change behaviour in directories.

In this post, I will try to explain the above statement. Then I will explain why you should care about setuid and setgid.

Let’s create two new files. Here I am using Ubuntu 20.04. Run the following command:

touch sample.txt
touch sample.sh
chmod u+x sample.sh

I have also given the execute permssion to owner of “sample.sh” file. You can put whatever you want in the files. I have the following content:

sample.txt

This is sample text file.

sample.sh

#!/bin/bashecho "This is sample bash file"

Let’s check the existing permissions on this file. Run the following command:

ls -l sample.txt sample.sh
-rwxr--r-- 1 prateek93a prateek93a 0 Nov 11 10:35 sample.sh
-rw-r--r-- 1 prateek93a prateek93a 0 Nov 11 10:35 sample.txt

Setuid:

Setuid stands for “set user ID”. As stated previously, it allows people to interact with a file with the permissions same as the owner of the file.

Run the following command:

chmod u+s sample.txt

Check the permissions on this file:

ls -l sample.txt
-rwSr--r-- 1 prateek93a prateek93a 0 Nov 11 10:35 sample.txt

We can see “S” in the permissions list. Since “sample.txt” is not executable, we see “S” in the output.

Now let’s set the special permission on “sample.sh”:

chmod u+s sample.sh

Again check the permissions on this file:

ls -l sample.sh
-rwsr--r-- 1 prateek93a prateek93a 0 Nov 11 10:35 sample.sh

For executable files(files having “x” bit set), we see “s” instead of “S”.

Setgid:

It stands for “set group ID” and act the same way as setuid does. Except in this case, the users executing your file will temperorily execute it with the priviledges of the group that you belong to.

To use setgid, you can run the following command:

chmod g+s sample.txt sample.sh

Now if you check the permissions you get:

ls -l sample.txt sample.sh
-rwsr-Sr-- 1 prateek93a prateek93a 0 Nov 11 10:35 sample.sh
-rwSr-Sr-- 1 prateek93a prateek93a 0 Nov 11 10:35 sample.txt

If you provide the execute permission to the group, you will have “s” in the output.

Why?

You may be wondering what is the use of having an entirely new file access permission. If you want others to be able to execute the file you have created, you can just give the execute permissions on the group as well as others. How is the special permission useful?

There’s a difference! Concentrate on the above mentioned wikipedia defination again. It implies that special permission bit allows users to execute the file with the same permissions as the owner of the file.

So, if the file is owned by root user, then you can temperorily assume the priviledges of the root user when you execute file. This means, the executable can will perform actions as if the root user has executed it.

Note that I have been saying executable file a lot, but you can set the special permission bit on any kind of file as shown in the above examples. Its just that, on a non-executable file or directory, the special permission is not really useful.

Let’s take some examples to understand this better.

passwd

If you have been using Linux for some time now, you must encountered the command “passwd”. It allows you to change the password corresponding your username. Basically “passwd” is a simple executable file located in “/usr/bin” that edits the password file (containing hashes of the passwords corresponding to users) based on the input you provide.

Let’s check permissions on this executable file:

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Jul 15 03:38 /usr/bin/passwd

It has “s” bit set for the root user.

You can’t directly make edits to the password file unless you are the root user. Hence, “passwd” lets you assume root priviledges and make changes to the entry corresponding to you in the password file.

If you look carefully, the “passwd” executable file is acting like an interface that allows editing of password file in certain manner. You can only edit your entry. You can’t edit other users’ entries. It is an extremely important property that can be achieved using the special file permission. If you were given the write access to the password file, you could change somebody else’s password hash or change the format of the file itself rendering it useless.

Hence you can have a file or directory or database for which you can create an interface to interact in a specified manner. This interface will be your executable file. Then you can set the special permission bit to allows others to use the interface.

sudo

Okay, this one is so common, I don’t even need to explain what this command does. “sudo” is just another executable located in “/usr/bin” directory. Basically, what this executable does is it allows you to run the commands provided as arguements with the same priviledge as root user.

Let’s check permissions on this executable file:

ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 166056 Jan 19  2021 /usr/bin/sudo

It also has “s” bit set for the root user.

When you type “sudo some-command”, it asks for the password corresponding to your username to verify your identity. It then checks if you have the permission to assume root priviledges by referencing the “sudoer file”. If you do have the permission, it executes the “some-command” with the same priviledge as root, as if the root user has run “some-command”.

This allows you to carry out tasks which require elevated permissions such as installing new packages in your system.

Here too, the “sudo” command is acting as an interface. It first checks if you have the permission to assume root priviledges.

Ofcourse, there a lot of other things you can do apart from providing an interface. It all depends on what code you write in the executable file. Important thing to remember is that the file will execute with the level of priviledges that you or your group has.

Security

With special permissions, you are basically allowing anyone to assume the same level of priviledges that you have when they execute the file. Depending on your priviledges and the code written in your executable file, it may or may not be a vulnerability. Hence it is very important to check the code before setting up the special permission bit.

A disclosure here. I used “sample.sh” as an example of executable file for showing the special permission. Even though you can see “s” in the permissions list, your OS won’t allow others to execute this file with your permissions. This is a security measure that applies to shell scripts. You can, however, create other executables like compiled code. Special permission bit will work on them.

If you are into cybersecurity and CTFs, OverTheWire Bandit Level 19 → Level 20 CTF is a nice example of how special permission bit can be exploited to gain priviledged access.

Summary

In my opinion, setuid and setgid are beautiful examples of application Principles of Least Priviledges. Instead of giving everyone an unrestricted access to sensitive files, one can write an interface that limits the kind of interaction users can have with the sensitive files. There can be security issues if you are not careful of the code in the executable file though.

That’s all folks! I hope I was enhance your knowledge about UNIX permissions just a “bit”.