Linux Labs
Where to start First steps track · 15 stages
Linux Labs
EN

Special permission bits: setuid, setgid, sticky

7 min Linux · GNU coreutils 9.4

Special permission bits: setuid and setgid run a program as its owner; setgid and sticky shape shared directories.

Cheat sheet

7 commands Printable version
  • ls -ld /tmp /usr/bin/passwd t on /tmp, s on passwd
  • sudo chmod g+s /srv/team setgid: new files get its group
  • sudo chmod +t /srv/team sticky: no deleting others' files
  • sudo chmod 3770 /srv/team both bits plus rwx for the group
  • stat -c '%a %A %n' /srv/team 3770 drwxrws--T /srv/team
  • sudo chmod g-s,-t /srv/team clear both bits
  • find / -perm -4000 -type f 2>/dev/null every setuid program

Overview

Besides rwx for the owner, group and others, a file has three more bits: setuid, setgid and sticky. In numeric mode they are the first of four digits: 4 is setuid, 2 is setgid, 1 is sticky. chmod 2775 = setgid + rwxrwxr-x.

Bit On a program On a directory In ls -l
setuid (4) runs with the file owner's rights — s for the owner
setgid (2) runs with the file's group new files get the directory's group s for the group
sticky (1) — only the owner can delete a file t for others

A capital letter means the bit is set but there is no x under it: S is setgid without g+x, T is sticky without o+x. For a directory, drwxrws--T is a normal picture: others cannot enter, and sticky works for the group members.

A shared directory: setgid and sticky together

A new file gets the primary group of whoever created it. In a shared directory that breaks teamwork: alice's file lands in group alice, and her colleagues cannot edit it. setgid on the directory changes the rule — the file gets the directory's group, and subdirectories inherit both the group and the bit itself.

w on a directory allows deleting any file in it, even someone else's. sticky leaves deleting and renaming to the file's owner, the directory's owner and root. This is how /tmp works:

text 
student@ubuntu:~$ ls -ld /tmp
drwxrwxrwt 11 root root 4096 Oct 20 06:30 /tmp

Group write access on new files comes from the creator's umask, not from the directory: shared work needs a mask of 002.

Recipes

3

A team directory

bash 
sudo groupadd devs
sudo usermod -aG devs alice          # add alice; she must log in again
sudo mkdir /srv/team
sudo chgrp devs /srv/team
sudo chmod 3770 /srv/team            # setgid + sticky + rwxrwx---
ls -ld /srv/team                     # drwxrws--T … root devs …

Check: alice's file gets group devs and group write access (with a 002 mask), and bob cannot delete it:

text 
student@ubuntu:~$ sudo -iu alice touch /srv/team/a.txt
student@ubuntu:~$ ls -l /srv/team
total 0
-rw-rw-r-- 1 alice devs 0 Oct 20 06:30 a.txt
student@ubuntu:~$ sudo -iu bob rm -f /srv/team/a.txt
rm: cannot remove '/srv/team/a.txt': Operation not permitted

Fix files that are already there

bash 
sudo chgrp -R devs /srv/team
sudo find /srv/team -type d -exec chmod g+s {} +

setgid works on new files. Old files and files moved in with mv keep their group — fix those by hand.

Find setuid and setgid programs

bash 
find / -perm -4000 -type f 2>/dev/null   # setuid
find / -perm -2000 -type f 2>/dev/null   # setgid

A clean system has a dozen or so: passwd, sudo, su, mount and the like. A new line in the list is a reason to find out who set the bit and why.

Troubleshooting

6

A new file in the shared directory has a personal group

The directory has no setgid (ls -ld shows x rather than s for the group) — run chmod g+s. If the bit is there, the file was not created but moved in with mv: it kept its old group, so fix it with chgrp.

A colleague deleted my file

The directory has no sticky bit, and the group has w. Run chmod +t.

rm: cannot remove 'x': Operation not permitted

The file is someone else's, and the directory has the sticky bit (t or T at the end of ls -ld). That is by design: only the file's owner, the directory's owner or root can delete it.

chmod 775 did not clear setgid on a directory

GNU chmod with a three- or four-digit number does not clear setuid and setgid on directories. Clear them with letters, chmod g-s dir, or with an extra leading zero: chmod 00775.

chmod: changing permissions of 'x': Operation not permitted

Only the file's owner and root can change its permissions. Check the owner in ls -l and use sudo if it is your machine.

setuid on a script does nothing

The Linux kernel ignores setuid on #! scripts — it applies only to programs. To run a command as root, configure sudo.

Danger zone

1

A stray setuid is a road to root

A root-owned setuid program that can read or write arbitrary files or run commands hands root to any user. Do not set u+s on your own programs or on copies of system ones, and keep the find -perm -4000 list under control.

Terms

3
setuid bit (SUID)
A special bit on an executable: the program runs with the file owner's rights, not those of the user who started it. ls -l shows s in place of the owner's x, as on /usr/bin/passwd. Also appears in: File permissions
setgid bit (SGID)
A special permission bit. On a directory, new files and subdirectories get the directory's group instead of the creator's primary group; on a program, it runs with the file's group. ls -l shows s in place of the group's x. Also appears in: File permissions, umask, Users and groups
sticky bit
A special bit on a directory: only the file's owner, the directory's owner or root can delete or rename a file in it. ls -l shows t in place of the others' x, as on /tmp. Also appears in: chmod / chown

See also

  • permissions — rwx, owner and group, numeric modes.
  • chmod-chown — chmod with letters and numbers, chgrp.
  • umask — which permissions new files are created with.
  • users-groups — a user's groups, usermod -aG.
  • acl — rights for individual users and groups beyond rwx.
  • find — searching by permissions with -perm.

Found an inaccuracy? Report an error in the article

Practice on this topic

Lessons on this topic

Tools on this topic

Topics
Loading…