Linux File Permissions
Linux file permissions through owner, group, mode bits, and directory access rules.
Linux file permissions are simple in structure and subtle in effect. Every file or directory has an owner, an associated group, and a permission set for everyone else. The familiar string -rwxr-xr-- is just a compact way to answer one question: who is allowed to do what to this inode?
Ownership comes first. The user owner is usually the account that created the file, although administrators can change it with chown. The group owner lets several users share access without making everything world-readable. Anyone who is neither the owner nor a member of that group falls into the other category. Linux checks permissions in that order, so a user gets the owner bits if they own the file, otherwise the group bits if they belong to the group, otherwise the other bits.
The r, w, and x bits also mean slightly different things for files and directories. On a regular file, r means the content can be read, w means the file can be modified or truncated, and x means the kernel may try to execute it. On a directory, r means the directory entries can be listed, w means entries can be created, renamed, or removed, and x means the directory can be traversed. That last detail is easy to miss. A user may know a filename exists but still be unable to access it if they lack execute permission on one of the parent directories.
Numeric modes are shorthand for the same model. chmod 644 means owner read-write, group read-only, other read-only. 755 usually marks directories or executable scripts: owner full access, everyone else read and traverse. 777 is rarely the right answer because it grants write access to everyone and usually indicates that ownership or group design was never set up properly.
Permissions are also shaped by defaults. When a process creates a file, the resulting mode is reduced by the process umask. That is why two machines running the same tool can create files with different permissions. Shared project directories often depend on both the group bits and the setgid bit on the directory so new files inherit the project group instead of the creator's primary group.
There are advanced flags too. setuid and setgid can run executables with the file owner's or group's privileges, which is powerful and risky. The sticky bit on directories such as /tmp allows many users to write there while preventing them from deleting one another's files.
The safest habit is to treat permissions as part of system design, not post hoc cleanup. Assign groups deliberately, grant the minimum needed rights, and remember that directory permissions control reachability as much as file permissions control content access. Once that clicks, Linux permissions stop feeling cryptic and start feeling predictable.