Search Knowledge

© 2026 LIBREUNI PROJECT

Operating Systems Internals / Advanced Topics & UNIX Deep Dive

Advanced UNIX Permissions and Security

Advanced UNIX Permissions and Security

UNIX file permissions fundamentally control what users and processes can do with files and directories. The basic read, write, and execute bits (rwx) for Owner, Group, and Others provide a robust security layer. However, complex real-world scenarios require advanced mechanisms beyond the standard 777 numeric notation.

Special Permissions: SUID, SGID, and the Sticky Bit

Three special bits exist to handle necessary privilege escalation or restricted deletion.

Set-User-ID (SUID)

When the SUID bit is set on an executable file, the process executing the file assumes the privileges of the file’s owner, not the user running it.

  • Example: The passwd command requires root access to modify /etc/shadow. Since /usr/bin/passwd is owned by root and has the SUID bit set, any user can run it to change their password securely.
  • Representation: An ‘s’ appears in the owner’s execute position: -rwsr-xr-x.
  • Command: chmod u+s /path/to/executable

Set-Group-ID (SGID)

Similar to SUID, SGID allows a process to assume the group privileges of the file’s group. When applied to a directory, it influences inheritance: any new file created within that directory automatically inherits the group ownership of the directory rather than the primary group of the user who created it.

  • Example: Collaborative directories where multiple members of a “developers” group need write access to newly created files.
  • Representation: An ‘s’ appears in the group’s execute position: drwxrwsr-x.
  • Command: chmod g+s /path/to/directory

The Sticky Bit

Historically used to keep executables “sticky” in RAM, the sticky bit is now primarily used on directories to restrict file deletion. When applied, only the file’s owner, the directory’s owner, or the root user can rename or delete files within it.

  • Example: The /tmp directory must be writable by everyone (chmod 777), but a user shouldn’t be able to delete another user’s temporary files.
  • Representation: A ‘t’ appears in the others’ execute position: drwxrwxrwt.
  • Command: chmod +t /tmp

Access Control Lists (ACLs)

Standard UNIX permissions are inherently limited to a single owner user and a single group. If a file needs to grant read access to “User A” and write access to “User B” who are not in the same group, traditional chmod fails. Access Control Lists (ACLs) solve this fine-grained security requirement.

Using setfacl and getfacl, administrators establish granular rules mapped to specific users and groups irrespective of the POSIX owner/group logic.

# View standard and potentially ACL assignments
ls -l project_data.txt
-rw-r--r--+ 1 admin staff 1024 Mar 14 project_data.txt

# The '+' indicates ACLs are present
getfacl project_data.txt
# file: project_data.txt
# owner: admin
# group: staff
user::rw-
user:alice:r--
user:bob:rw-
group::r--
mask::rw-
other::r--

In this scenario, Alice is explicitly granted read-only access, while Bob has read and write capabilities, overriding the default generic POSIX attributes.

Exercise: Resolving Permission Escalation Vectors

Case Study Setup

A corporate server has a sensitive configuration file located at `/etc/application/config.yaml`. The file is currently owned by the `root` user and the `sysadmin` group. A new requirement mandates that an intern named Alice (in the group `interns`) and a contractor named Bob (in the group `contractors`) both need read and write access to exactly this file, but neither should be added to the powerful `sysadmin` group.

Since standard POSIX permissions are limited to a single owner and group, what specific mechanism must the administrator employ to fulfill this precise requirement securely?