Who Can Do What?
Imagine a Linux system as a large office building. Every file and directory is a room in that building. You wouldn't want just anyone walking into the CEO's office or the server room. Someone needs to control access.
Linux uses a robust permissions model to act as the security guard, deciding who is allowed to enter which room and what they are allowed to do once inside. This isn't optional security theater—it's the foundation of multi-user system safety. Without it, any user could read your SSH keys, modify system binaries, or delete another user's work.
Every file and directory on a Linux system has two pieces of ownership metadata attached to it:
- Owner (User): A single user account that "owns" the file
- Group: A collection of user accounts that share access
Based on this ownership, Linux defines three sets of permissions for three categories of people:
- User (u): The owner of the file
- Group (g): Any user who is a member of the file's group
- Others (o): Everyone else on the system who has an account
When you try to open a file, the kernel checks these permissions in order: Are you the owner? If yes, use owner permissions. If no, are you in the group? If yes, use group permissions. If no, use "others" permissions. The first match wins—group permissions don't apply to the owner even if the owner is in the group. This means if the owner has fewer permissions than the group, the owner still gets the lesser permissions.
Key Point: Permissions are enforced by the kernel at the system call level. User-space programs cannot bypass them. Even if you write a custom program in C that tries to open a file, the
open()system call will fail if permissions deny access. This is why permissions are trustworthy—they're not just a suggestion, they're a hard boundary enforced by the operating system itself.