Setuid, Setgid and Sticky Bit in Linux: What They Do on Files and Directories

Updated: 11 October 2026 · Applies to: Linux: Debian 13 (GNU chmod 9.7), AlmaLinux 10 (GNU chmod 9.5) and Ubuntu 26.04 (uutils chmod 0.10.0)

Linux has three special permission bits on top of read, write and execute. The setuid bit (octal 4, u+s) makes a program run with the rights of the file's owner instead of the user who starts it; on a directory Linux ignores it. The setgid bit (octal 2, g+s) makes a program run with the file's group, and on a directory it makes new files and folders inherit the directory's group. The sticky bit (octal 1, +t) on a directory such as /tmp means only a file's owner, the directory's owner or root can delete or rename that file.

chmod u+s /usr/local/bin/tool     # setuid   (same as chmod 4755)
chmod g+s /srv/shared             # setgid   (same as chmod 2775 on a 775 folder)
chmod +t  /srv/drop               # sticky   (same as chmod 1777 on a 777 folder)

All the output below is from Debian 13. Ubuntu 26.04 (which uses the Rust uutils version of chmod) and AlmaLinux 10 behaved the same.

How to recognise the special bits in ls -l

$ ls -l /usr/bin/passwd /usr/bin/chage
-rwxr-sr-x 1 root shadow 113848 Apr 19 10:20 /usr/bin/chage
-rwsr-xr-x 1 root root   118168 Apr 19 10:20 /usr/bin/passwd
$ ls -ld /tmp
drwxrwxrwt 2 root root 4096 Oct  5 00:00 /tmp
$ stat -c "%a %A %n" /tmp /usr/bin/passwd
1777 drwxrwxrwt /tmp
4755 -rwsr-xr-x /usr/bin/passwd

• s in the owner's execute position: setuid (passwd).
• s in the group's execute position: setgid (chage on Debian runs with the shadow group).
• t in the others' execute position: sticky bit (/tmp).
• A capital S or T means the special bit is set but the execute bit under it is not, which is usually a mistake:

  -rwSr--r-- 1 root root    0 Oct  9 18:30 /srv/f1
  -rw-r-Sr-- 1 root root    0 Oct  9 18:30 /srv/f2
  drwxrwx--T 2 root root 4096 Oct  9 18:30 /srv/d1

In the four-digit octal mode the first digit is the sum of the special bits: 4 setuid, 2 setgid, 1 sticky. So 4755 is setuid plus rwxr-xr-x, and 1777 is sticky plus full access for everyone. See Translate rwx Permissions into Octal Format in Linux for the other three digits.

The setuid bit on files

When an executable has the setuid bit and belongs to root, any user who runs it gets root's rights for that program. That is how a normal user can change their own password with passwd, which has to write to /etc/shadow. To see the effect, we copied the id command, made it setuid root and ran it as the user vipin:

$ su - vipin -c "id"
uid=1001(vipin) gid=1002(vipin) groups=1002(vipin),1000(webteam)
$ su - vipin -c "/srv/myid"
uid=1001(vipin) gid=1002(vipin) euid=0(root) groups=1002(vipin),1000(webteam)

euid=0(root) is the effective user ID: the copy runs as root. This is why a setuid root program with a bug is a serious risk, and why you should never set it on your own tools unless you have to. Two things we confirmed in the test:

• Linux ignores setuid on scripts. A #!/bin/sh script with mode 4755 owned by root still printed vipin for id -un. Use sudo rules for scripts instead.
• chown clears the setuid bit. After chown anita /srv/f4 a 4755 file became -rwxr-xr-x, so set the bit again after changing the owner.

Setuid on a directory

Linux ignores the setuid bit on directories. GNU's documentation says only "a few systems" give it a meaning for new files. In our test the directory showed the bit, but a file created in it still belonged to the user who made it:

$ ls -ld /srv/suiddir
drwsrwxrwx 2 root root 4096 Oct  9 18:30 /srv/suiddir
$ su - vipin -c "touch /srv/suiddir/vipin.txt"; ls -l /srv/suiddir
total 0
-rw-rw-r-- 1 vipin vipin 0 Oct  9 18:30 vipin.txt

To make new files in a folder belong to a shared owner, use setgid with a shared group (next section) or change the owner with Change File and Folder Ownership in Linux (chown, chgrp).

Setgid on a directory: a shared folder for a team

This is the most useful special bit on a server. Files created in a setgid directory get the directory's group instead of the creator's own group, and new subdirectories get the setgid bit too, so the rule carries down the tree.

1. Create a group and add the users to it (they must log in again to pick up the group):

   groupadd webteam
   usermod -aG webteam anita
   usermod -aG webteam vipin

2. Give the folder to that group and set the setgid bit:

   $ chown root:webteam /srv/shared && chmod 2775 /srv/shared && ls -ld /srv/shared
   drwxrwsr-x 2 root webteam 4096 Oct  9 18:30 /srv/shared

3. Check it as one of the users:

   $ su - anita -c "touch /srv/shared/anita.txt; mkdir /srv/shared/reports"
   $ ls -l /srv/shared
   total 4
   -rw-rw-r-- 1 anita webteam    0 Oct  9 18:30 anita.txt
   drwxrwsr-x 2 anita webteam 4096 Oct  9 18:30 reports

Both new items belong to webteam, and reports carries the s as well. The same touch in a normal 775 folder gave anita anita. Setgid only sets the group; whether other members can edit a file depends on its group write bit, which comes from the user's umask (it was 002 for these users, so files were rw-rw-r--). Existing files keep their old group: fix them once with chgrp -R webteam /srv/shared.

The sticky bit: what it is in Unix and Linux

On a directory the sticky bit is the "restricted deletion flag". Everyone can create files in /tmp, but nobody can delete or rename someone else's file there. In our test anita created a file in a 1777 folder and vipin tried to remove it:

$ su - vipin -c "rm /srv/drop/anita.txt"
rm: cannot remove '/srv/drop/anita.txt': Operation not permitted
$ su - vipin -c "mv /srv/drop/anita.txt /srv/drop/x.txt"
mv: cannot move '/srv/drop/anita.txt' to '/srv/drop/x.txt': Operation not permitted

In a 0777 folder without the sticky bit, the same rm worked. The name comes from old Unix systems, where the bit on a program kept its code in swap so it loaded faster. The GNU chmod manual describes that use only for "some older systems"; on Linux the sticky bit matters on directories.

How to set and remove the special bits

• Set: chmod u+s FILE, chmod g+s DIR, chmod +t DIR (or o+t), or the numeric forms 4755, 2775 and 1777.
• Remove: chmod u-s FILE, chmod g-s DIR, chmod -t DIR.

Watch out with directories: a plain numeric chmod does not clear setgid on a directory. This happened with GNU and uutils chmod alike:

$ chmod 755 /srv/shared && ls -ld /srv/shared
drwxr-sr-x 3 root webteam 4096 Oct  9 18:30 /srv/shared
$ chmod 0755 /srv/shared && ls -ld /srv/shared
drwxr-sr-x 3 root webteam 4096 Oct  9 18:30 /srv/shared
$ chmod 00755 /srv/shared && ls -ld /srv/shared
drwxr-xr-x 3 root webteam 4096 Oct  9 18:30 /srv/shared

Use chmod g-s or five digits (00755). On regular files, chmod 755 does clear the bits.

Find files and folders with these bits

find / -xdev -perm -4000 -type f 2>/dev/null     # setuid files
find / -xdev -perm -2000 -type f 2>/dev/null     # setgid files
find / -xdev -perm -1000 -type d 2>/dev/null     # sticky directories

On Debian 13 with sudo installed the setuid list was mount, chfn, su, umount, passwd, chsh, newgrp, gpasswd and sudo, and the sticky directories were /tmp, /var/tmp and /run/lock. On Ubuntu 26.04, /usr/bin/sudo is a symlink, so ls -l shows no s; the setuid files are /usr/lib/cargo/bin/sudo (sudo-rs) and /usr/bin/sudo.ws (classic sudo). Use ls -lL to see the target's mode. A setuid file you did not install yourself is worth checking: see How to Find Files With SUID and SGID Permissions in Linux? for an audit routine.

Related: chmod 755, 644 and 600 Explained: rwxr-xr-x Permission Codes explains the normal 755 and 644 permissions, and How to Read ls -l Output in Linux: Permissions, Links, Owner, Size and Date Explained reads every column of ls -l.

Official documentation: inode(7) file mode bits, GNU coreutils: directory setuid and setgid.