File Protection

Introduction

In a multi-user system, file protection is essential. Without it, any user could read your private emails, modify your programs, or delete your research data. File protection mechanisms control WHO can do WHAT to each file. The operating system enforces these rules at every file access, acting as a security guard that checks credentials before allowing entry.

File protection is not optional — it is the foundation of multi-user system security. Every operating system, from Unix to Windows to macOS, implements file protection because without it, sharing a computer between multiple users would be impractical and dangerous.

Types of Access

Files can be accessed in different ways, and protection must control each independently:

• Read (r): View file contents — cat, less, open for reading
• Write (w): Modify file contents — edit, truncate, overwrite
• Execute (x): Run the file as a program or script
• Append: Add data to end without modifying existing content (some systems support this separately)
• Delete: Remove the file from the directory
• List: View file attributes and metadata (permissions, size, timestamps)

Different combinations serve different purposes. A log file might be append-only (new entries added, existing ones never modified). A shared library needs read and execute but not write. A configuration file needs read by services but write only by administrators.

Unix Permission Model

Unix uses a simple but effective three-category permission system that has endured for over 50 years:

Permission Values (Octal Notation)

Directory Permissions

Permissions mean different things for directories:

Key insight: Without execute on a directory, you cannot access anything inside it — even if the files inside have read permission. Without read, you cannot list contents but CAN access files if you know their exact names (provided you have execute).

Special Permissions

Beyond basic rwx, three special permission bits handle specific scenarios:

SUID (Set User ID): When set on an executable, it runs with the file owner's permissions regardless of who executes it. The passwd command is SUID root because it needs to modify /etc/shadow (owned by root), but any user should be able to change their own password.

SGID (Set Group ID): On executables, runs with the file's group. On directories, new files inherit the directory's group (enabling shared project folders).

Sticky bit: On directories, prevents users from deleting files they do not own, even if they have write permission on the directory. Classic example: /tmp (everyone can create files, but only delete their own).

Access Control Lists (ACLs)

Unix's three-category model (owner, group, other) is sometimes insufficient. What if you need to give specific read access to user Bob without adding him to the file's group?

ACLs provide per-user and per-group permission entries:

Linux ACL Commands

Windows NTFS uses ACLs natively with even finer granularity — separate permissions for reading attributes, writing attributes, creating child objects, deleting, changing permissions, and taking ownership.

Access Matrix Model

The theoretical foundation for all access control systems is the access matrix — a table with subjects (users/processes) as rows and objects (files/resources) as columns:

This matrix is typically too large and sparse to store directly. Two implementation approaches exist:

Access Control Lists (column-based): For each object, store the list of subjects and their permissions. Answer: "Who can access this file?"

Capability Lists (row-based): For each subject, store the list of objects they can access. Answer: "What can this user do?"

Protection Enforcement

The OS kernel checks permissions on EVERY file operation — this cannot be bypassed by user programs:

This check happens at the system call boundary — the transition point between user code and kernel code. Since user programs cannot bypass system calls to access files directly (hardware memory protection prevents it), the permission check is inescapable.

Protection vs. Security

Important distinction:

• Protection deals with mechanisms: how the OS enforces access policies
• Security deals with policies: what access should be allowed and detecting/preventing attacks

A system can have perfect protection mechanisms but poor security if the policies are misconfigured (e.g., making sensitive files world-readable by mistake).

Key Takeaways

• File protection controls who can read, write, execute, or delete each file
• Unix uses a three-level model: owner, group, others — each with rwx permissions
• Special permissions (SUID, SGID, sticky bit) handle privilege escalation and shared directories
• ACLs provide fine-grained per-user/per-group permissions beyond Unix's three categories
• The access matrix is the theoretical model; ACLs and capabilities are practical implementations
• Protection is enforced by the OS kernel at the system call boundary — cannot be bypassed by user programs
• Proper file permissions are the first line of defense in multi-user system security