Introduction
In Linux, the behavior of a file is set or controlled by two mechanisms: file ownership and file permissions. The ownership of files or directories is normally based on the default uid
(User ID) gid
(Group ID) of the the user who created them. Regarding the file permissions, a default set of permissions (755
for directories, 644
for the files) are assigned to a file or directory when it is created. If preferred, these default permissions can be changed by the umask
command.
The file ownership not only determines who can access a file but also how a file behaves when it is run. This is due to the fact that when a file is executed, it runs with the effective uid
and gid
of the user who started it.
To change file ownership and file permissions, chown
and chmod
commands can be used respectively. Through the chmod
command, Read (r), Write (w) or eXecute (x) privileges can be set for the owner of the file, to the group or to all the other users. In addition to these three modes (r
, w
, x
), a set of permissions that are collectively known as special modes (SetUID, SetGID and Sticky Bit) can also be set through the chmod
command to further control the file permissions.
In this article, we explain what these special file permissions (SetUID, SetGID and Sticky Bit) modes are, why they are needed and how to set or unset them with practical examples.
SetUID
As described briefly above, when a file is executed (if the execution bit is set), it runs with the effective uid
and gid
of the user who started it. However, this default behavior can be changed by modifying the setuid
flag on the file permissions bits. When the setuid
flag is set, an executable file does not run with privileges of the user who launched it, but with that of the file owner instead. So, for instance, if an executable file has its setuid
bit is on and it is owned by the root
, it will be executed with root
privileges even when a normal user (with execute privileges) launches it.
To give an example, let’s explore the passwd
command for which the default permissions are depicted below.

/bin/passwd
CommandAs the output of the ls -la
command shows, the file passwd
is owned by the root, i.e., its effective uid
and gid
are set as the root
user. Also, note that the setuid
bit is set for the passwd
command by the bit flag s
in place of the executable bit (x
). This is denoted in the first octal (owner permissions) of the permissions bits.
To explain the notation a little bit more, the bit flag s
denotes that both the executable (x
) and the setuid
flags are set while a capital S
indicates that only the setuid
flag is on and the executable (x
) flag is not. In the latter case, the setuid
permission has actually no effect as the file is not executable at all.
Going back to example, since all the other users have the read (r
) and execute (x
) permissions on the passwd
command, when it is run by a normal user, it will be executed with the privileges of the root
user, instead of the privileges of the user launching the passwd
command.
So far so good. But why this setuid
feature is needed and what is it good for? To answer this question, let’s have a look at the permissions on the /etc/shadow
file that is being used by the /bin/passwd
command under the hood to change users’ passwords.

As can be seen from the output given above, only the root
user can modify this file while shadow group can only read it and the rest of the users have no permissions at all. In this case, if the passwd
command did not have its setuid
bit set, normal users could execute the command successfully but they would not be allowed to change any user passwords since they did not have the write permission on the /etc/shadow
file.
You might further ask why the users can not change the /etc/shadow
file directly to prevent all this confusion? The answer to this question is that normal users would have the full capability to change any password other than their own. However, through this carefully designed privilege mechanism, ordinary users can modify the /etc/shadow
file, but with a restricted capability controlled by the /bin/passwd
command that allows users only to change their own passwords. Actually, this example demonstrates a good example of the Least Privilege Principle for secure system design.
To set the setuid
bit, you can use the following commands, with numerical and symbolic notations respectively.
$ chmod 4644 filename
$ chmod u+s filename
To unset the setuid
bit, you can use the following commands, with numerical and symbolic notations respectively.
$ chmod 0644 filename
$ chmod u-s filename
To search for the files that are owned by the root
user and have their setuid
bit set, you can use the following commands.
$ find / -user root -perm -4000 -ls 2> /dev/null
$ find / -user root -perm -u=s -ls 2> /dev/null
As depicted below, sudo
command is another good example for the setuid
special permission. Through the capability provided by the setuid
flag on the sudo
command, normal users can run other commands with the privileges of the root
user.

SetGID
The setgid
bit is very similar in functionality to the setuid
bit except that it affects both files as well as directories. When set on a file, it is run with the privileges of the group which own the file rather than the user who launched it. In the case of setting the setgid
bit on a directory, files created inside that directory will be owned by the group that of the parent directory rather than the group to which the user, who created the file, belongs to.
The setgid
flag is represented with an s
character in the second octal (group permissions) of the file permission bits.
To set the setgid
bit, you can use the following commands, with numerical and symbolic notations respectively.
$ chmod 2644 filename
$ chmod g+s filename
To unset the setgid
bit, you can use the following commands, with numerical and symbolic notations respectively.
$ chmod 0644 filename
$ chmod g-s filename
To locate the files that are owned by the root
user and have their setgid
bit set, you can use the following commands.
$ find / -user root -perm -2000 -ls 2> /dev/null
$ find / -user root -perm -g=s -ls 2> /dev/null
For instance, the crontab
command runs with the privileges of the crontab
group irrespective of the user who launches it.

Security Concerns over SetUID and SetGID
As explained above, both the SetUID
and SetGID
are necessary rather than being extraneous features in Linux. However, they should be used only when necessary and carefully. Again, as discussed briefly above, this is what the Least Privilege Principle dictates as a best security principle.
Secondly and more importantly, these privilege bits could lead to serious security issues due to the risk that they could allow attackers to conduct privilege escalation attacks. If a file that has its SetUID
or SetGID
bit set is vulnerable to Buffer Overflow attacks, then attackers can run their malicious code with the root
privileges by corrupting the memory. Thus, only executables which are considered to be secure should be assigned the SetUID
or SetGID
privileges. To minimize the security risks, some operating systems even ignore these bits for executable shell scripts.
Sticky Bit
The last of the special permissions, sticky bit
is only used with the directories and has no effect on files. When a directory has its sticky bit set, the files that it contains can still be accessed or modified according the file permissions. However, only the file owner, directory owner or the root user can only rename or delete these files. In other terms, sticky bit further can specify who can delete or rename the files contained in a directory in addition to the regular file permissions.
The sticky bit
flag is represented with a t character in the third octal (other user permissions) of the file permission bits.
To set the sticky bit
, you can use the following commands, with numerical and symbolic notations respectively.
$ chmod 1644 directoryname
$ chmod +t directoryname
To unset the sticky bit
, you can use the following commands, with numerical and symbolic notations respectively.
$ chmod 0644 directoryname
$ chmod -t directoryname
To search for the directories that have their stick bi
t set, you can use the following commands.
$ find / -perm -1000 2> -ls /dev/null
$ find / -perm -o=t 2> -ls /dev/null
To give an example, the /tmp
directory has its sticky bit
flag set, so that files created under this directory can only be deleted or renamed by the owner, or the root user. Thus other users can not delete it accidentally or deliberately.

To learn more on Linux, you could also read our article Basic Linux Commands for Beginners or visit Linux Resources Page.