Understanding Linux Special permissions - Sticky Bit, SUID, SGID

Special Permissions

Special permissions constitute a fourth permission type in addition to the basic user, group, and other types. As the name implies, these permissions provide additional access-related features over and above what the basic permission types allow. This section details the impact of special permissions, summarized in the table below.

SPECIAL PERMISSION EFFECT ON FILES EFFECT ON DIRECTORIES
u+s (suid) File executes as the user that owns the file, not the user that ran the file. No effect.
g+s (sgid) File executes as the group that owns the file. Files newly created in the directory have their group owner set to match the group owner of the directory.
o+t (sticky) No effect. Users with write access to the directory can only remove files that they own; they cannot remove or force saves to files owned by other users.

The setuid permission on an executable file means that commands run as the user owning the file, not as the user that ran the command. One example is the passwd command:

[user@host ~]$ ls -l /usr/bin/passwd
-rwsr-xr-x. 1 root root 35504 Jul 16  2010 /usr/bin/passwd

In a long listing, you can identify the setuid permissions by a lowercase s where you would normally expect the x (owner execute permissions) to be. If the owner does not have execute permissions, this is replaced by an uppercase S.

The special permission setgid on a directory means that files created in the directory inherit their group ownership from the directory, rather than inheriting it from the creating user. This is commonly used on group collaborative directories to automatically change a file from the default private group to the shared group, or if files in a directory should be always owned by a specific group. An example of this is the /run/log/journal directory:

[user@host ~]$ ls -ld /run/log/journal
drwxr-sr-x. 3 root systemd-journal 60 May 18 09:15 /run/log/journal

If setgid is set on an executable file, commands run as the group that owns that file, not as the user that ran the command, in a similar way to setuid works. One example is the locate command:

[user@host ~]$ ls -ld /usr/bin/locate
-rwx--s--x. 1 root slocate 47128 Aug 12 17:17 /usr/bin/locate

In a long listing, you can identify the setgid permissions by a lowercase s where you would normally expect the x (group execute permissions) to be. If the group does not have execute permissions, this is replaced by an uppercase S.

Lastly, the sticky bit for a directory sets a special restriction on deletion of files. Only the owner of the file (and root) can delete files within the directory. An example is /tmp:

[user@host ~]$ ls -ld /tmp
drwxrwxrwt. 39 root root 4096 Feb  8 20:52 /tmp

In a long listing, you can identify the sticky permissions by a lowercase t where you would normally expect the x (other execute permissions) to be. If other does not have execute permissions, this is replaced by an uppercase T.

Setting Special Permissions

- Symbolically: setuid = u+s; setgid = g+s; sticky = o+t - Numerically (fourth preceding digit): setuid = 4; setgid = 2; sticky = 1

Examples

1. Add the setgid bit on directory:

[user@host ~]# chmod g+s directory

2. Set the setgid bit and add read/write/execute permissions for user and group, with no access for others, on directory:

[user@host ~]# chmod 2770 directory