Linux Special Permissions: SUID, SGID, Sticky Bit and ACLs

Standard Linux permissions (read, write and execute for owner, group and others) cover most needs. Sometimes, however, you need more control. Linux special permissions, SUID, SGID and the sticky bit, change how programs run and how shared directories behave. Access control lists (ACLs) go further by granting permissions to specific extra users and groups.

This guide explains each feature with practical examples and the security points to watch. If you need a refresher first, read Linux file and directory permissions.

Overview

Feature	Applies to	Effect	Symbol	Numeric
SUID	Executable files	Runs with the file owner’s privileges	`s` in owner execute	4000
SGID	Files	Runs with the file group’s privileges	`s` in group execute	2000
SGID	Directories	New files inherit the directory’s group	`s` in group execute	2000
Sticky bit	Directories	Only the owner can delete or rename their files	`t` in others execute	1000

A capital S or T in ls -l output means the special bit is set but the matching execute bit is not.

SUID (set user ID)

When a user runs an SUID program, it runs with the privileges of the file’s owner, not the user. The classic example is passwd, which must update /etc/shadow, a file only root can write.

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root ... /usr/bin/passwd

Set or remove SUID:

sudo chmod u+s /usr/local/bin/tool
sudo chmod u-s /usr/local/bin/tool

Security note: SUID-root programs are a favourite target for privilege escalation. Keep the list short, and review it during audits:

sudo find / -xdev -perm -4000 -type f 2>/dev/null

SGID (set group ID)

On files, SGID makes a program run with the file’s group. On directories, it is more useful: every new file created inside inherits the directory’s group. As a result, team folders stay accessible to the whole team.

sudo mkdir /srv/projects
sudo chgrp developers /srv/projects
sudo chmod 2775 /srv/projects

Sticky bit

In a shared directory with the sticky bit, users can create files, but they can delete or rename only their own files. The /tmp directory is the standard example:

ls -ld /tmp
drwxrwxrwt 15 root root ... /tmp

Set it on a shared folder:

sudo chmod +t /srv/shared
# or
sudo chmod 1777 /srv/shared

Access control lists (ACLs)

Standard permissions allow only one owner and one group. ACLs let you add permissions for extra users and groups on the same file or directory. Most modern file systems, such as ext4 and XFS, support ACLs by default.

View ACLs

getfacl report.txt

Grant access to a user or group

setfacl -m u:alice:rw report.txt
setfacl -m g:auditors:r report.txt

Set default ACLs on a directory

Default ACLs apply automatically to new files created inside:

setfacl -d -m g:developers:rwx /srv/projects

Remove ACLs

setfacl -x u:alice report.txt   # remove one entry
setfacl -b report.txt           # remove all ACL entries

A + at the end of the permission string in ls -l shows that a file has an ACL.

The ACL mask

The mask entry limits the maximum permissions for named users and groups. If an ACL seems to have no effect, check the mask in the getfacl output.

Best practices

Use SGID directories and groups for team folders before reaching for ACLs.
Use ACLs when you need exceptions, such as read-only access for auditors.
Never set SUID on scripts or editors.
Review SUID and SGID files regularly, and compare them with a known-good list.
Document why each ACL exists.

Related guides

Sources

The Linux man-pages project

Running Linux servers in production? Our Linux server hardening & security audit checks configuration, patching, SSH and logging. You can also use our free Linux server hardening checklist, or contact us.