Distinguish SUID, SGID and Sticky Bits

Ordinary read, write and execute bits do not describe every permission behavior you will encounter. Three classic special bits are SUID, SGID and sticky. They have different purposes, so learning them as one vague 'extra access' switch would be misleading.

We will start with a shared school directory and SGID group inheritance. Then we will distinguish executable identity changes from directory deletion restrictions. Keep the entry type in view: a bit set on a directory can have a different effect from a bit on an executable file.

Prepare the example

Use a disposable folder on the practice Linux VM. The example creates shared and sets a known mode. Whether the selected group and special bit are retained depends on your ownership, memberships and system rules; inspect the result. We are not building a privileged script or granting access to system files.

Bash · Linux terminal

mkdir shared
chmod 2770 shared
ls -ld shared

Expected behavior; machine-dependent details

The mode begins drwxrws--- when SGID is retained.

In chmod 2770 shared, the leading 2 requests SGID. The ordinary 770 gives owner and group full ordinary directory bits, with none for others. When the SGID directory behavior applies, new children inherit the directory's owning group, which helps keep a shared team's files in the intended role.

SGID does not itself grant a newly created child every desired read/write bit; creation mode, umask and default ACL behavior still matter. SUID and executable SGID concern eligible executable identities under system rules, and Linux does not honor that privilege mechanism on ordinary interpreted scripts. Sticky, by contrast, restricts removing or renaming directory entries by otherwise permitted users. It does not encrypt reports or make writable file bytes immutable.

Linux has three classic special permission bits in addition to normal read, write and execute permissions: SUID, SGID and the sticky bit. Each changes how execution or directory access behaves.

What Are Special Permissions?

In Linux, we usually talk about read (r), write (w), and execute (x) permissions for files and directories.

But there are three special permissions that give extra behavior to files or directories:

• SUID – Set User ID
• SGID – Set Group ID
• Sticky Bit

Let’s understand each with examples.

SUID – Set User ID

For an eligible executable binary, SUID changes the process’s effective user identity to the file owner. It does not bypass every access rule, and mount options or security policy can prevent the effect. Linux does not honor this privilege mechanism on ordinary shell scripts.

Let’s check if any file already uses it:

ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 54256 /usr/bin/passwd

Notice the s in place of the user’s execute bit: rws. That’s SUID!

This allows normal users to change their password (which updates /etc/shadow, owned by root), safely.

To show the SUID mode bit on a file (this does not grant SUID execution to an ordinary Linux shell script):

chmod u+s myscript.sh

To remove it:

chmod u-s myscript.sh

SGID – Set Group ID

When applied to a directory, all new files inside it inherit the directory's group.

This is useful for shared folders.

Create a shared directory:

mkdir shared-folder
chmod g+s shared-folder

Check the permissions:

ls -ld shared-folder

drwxr-sr-x 2 user group 4096 Jul 2 12:00 shared-folder

The s in the group section shows SGID is set.

On an eligible executable binary, SGID can change the effective group identity, subject to mount and security policy. Ordinary interpreted Linux scripts do not gain this execution behavior.

To add SGID:

chmod g+s myscript.sh

To remove it:

chmod g-s myscript.sh

Sticky Bit

The sticky bit is used mostly on directories, like /tmp.

It means: the file owner, directory owner or a suitably privileged process can remove entries, subject to other checks in the directory—even if others have write access.

Without sticky restrictions, users with the necessary parent-directory permissions may remove entries regardless of the file owner.

Let’s apply it to a directory:

mkdir project-temp
chmod +t project-temp

Verify it:

ls -ld project-temp

drwxrwxrwt 2 user group 4096 Jul 2 12:15 project-temp

The t indicates sticky together with others execute/search permission; an uppercase T indicates sticky without that execute bit. This listing illustrates a shared writable directory. The commands shown add sticky only: they do not grant the other write bits displayed here, and your new directory’s ordinary permissions depend on its creation mode and umask.

To remove it:

chmod -t project-temp

Compare SUID, SGID and the sticky bit side by side

Use the leading octal digit for special permission bits

You can use octal notation for special permissions:

• chmod 4755 file – SUID
• chmod 2755 file – SGID
• chmod 1755 file – Sticky bit

The first digit (4, 2, or 1) sets the special permission.

Compare SUID, SGID and the sticky bit

Now you know what SUID, SGID, and the Sticky Bit are—and how to test them yourself. Practice using them safely in test directories first.

The older command forms below include setting a special bit on a script name. They demonstrate the mode notation, not a working way to grant a Bash script privileged execution. Linux does not honor the ordinary SUID/SGID execution mechanism on interpreted scripts. Seeing an s in a listing therefore does not prove that every kind of file will run with a different effective identity.

For eligible binary executables, mount options such as nosuid and other policy can still restrict the effect. For directories, SGID is about group inheritance, while sticky concerns entry removal. Neither grants every desired operation by itself. Read the ordinary bits, the entry type and the surrounding access policy before making a claim about the special bit.

See the chmod manual for special-bit behavior.

Your task: Does SUID on an ordinary shell script reliably run it as the script owner on Linux?

Use a disposable folder on the practice Linux VM. The example creates shared and sets a known mode. Whether the selected group and special bit are retained depends on your ownership, memberships and system rules; inspect the result. We are not building a privileged script or granting access to system files.

Bash · complete example for this question

mkdir shared
chmod 2770 shared
ls -ld shared

Expected behavior; machine-dependent details

The mode begins drwxrws--- when SGID is retained.

Worked answer

No; Linux does not honor that execution mechanism for ordinary scripts.

Do not expect an ordinary shell script to run as its owner merely because you set SUID. A mode bit can be displayed without providing that execution mechanism. For the sticky question, keep entry removal separate from modification of a file's contents.

Name the special bit, entry type and intended effect before setting it. Group inheritance, executable identity and restricted deletion are separate mechanisms. Verify both special and ordinary bits, and use documented policy rather than treating a mode change as a general privilege guarantee.