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
passwdcommand requires root access to modify/etc/shadow. Since/usr/bin/passwdis owned byrootand 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
/tmpdirectory 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
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.