File Permissions and Ownership

In Linux, every file and directory has an owner and a group, and a set of permissions that control what the owner, the group, and everyone else can do with it. This system is the foundation of security: it prevents unauthorised users from viewing your files, changing settings, or running dangerous programs.

The three basic permission types are read, write, and execute. For a file, read (r) means you can view its contents, write (w) means you can modify or delete it, and execute (x) means you can run it as a program. For a directory, read means you can list its contents (the names of files inside), write means you can create or delete files within that directory, and execute means you can enter that directory (using the 'cd' command) and access the files inside it. Without execute on a directory, you cannot get into it at all.

Permissions are displayed by the 'ls -l' command. An example output line is: -rwxr-xr-- 1 alice developers 1024 Jan 1 10:00 script.sh

The first character tells you the type: '-' means a regular file, 'd' means a directory. The next nine characters are three groups of three: the first three are for the owner (user), the next three for the group, and the last three for others. In the example, owner alice has rwx (read, write, execute), members of the developers group have r-x (read and execute, but not write), and everyone else has r-- (read only).

Changing permissions is done with the 'chmod' command. You can use symbolic mode, like 'chmod u+x script.sh' to add execute for the user, or numeric (octal) mode. In numeric mode, each permission has a value: r=4, w=2, x=1. Sum them per group: owner, group, others. So rwx is 4+2+1=7, r-x is 4+0+1=5, r-- is 4+0+0=4. 'chmod 754 script.sh' sets the exact same permissions as the example above.

Changing ownership is done with 'chown' and 'chgrp'. 'chown alice script.sh' makes alice the owner. 'chown alice:developers script.sh' sets both owner and group at once. 'chgrp developers script.sh' changes only the group. Only the root user or the current owner can change ownership.

There are also three special permissions: setuid, setgid, and the sticky bit. Setuid (shown as 's' in the owner execute position) means that when a user runs the executable file, that program runs with the file owner's privileges, not the user's. This allows a normal user to change their own password, for example, because the 'passwd' command has setuid and runs as root. Setgid (shown as 's' in the group execute position) does the same but for group permissions. On a directory, setgid means that new files created inside it inherit the directory's group, not the creator's primary group. The sticky bit (shown as 't' in the others execute position) on a directory means that only the owner of a file inside that directory can delete or rename their own file, even if others have write permission on the directory. The classic use is '/tmp', where any user can create files but cannot delete someone else's files.

You can set these special modes with 'chmod' using the numbers 4 for setuid, 2 for setgid, and 1 for sticky bit, placed before the three normal digits. For example, 'chmod 1777 /tmp' sets the sticky bit with full rwx for everyone.

Default permissions for new files and directories are controlled by the 'umask' setting. Umask removes permissions from the base value (usually 666 for files, 777 for directories). A common umask of 022 means write permission is removed for group and others, so new files get 644 (rw-r--r--) and new directories get 755 (rwxr-xr-x).

A typical IT professional’s work with file permissions often begins the moment they onboard a new employee. Imagine a company called 'Acme Corp' hires a new developer named Bob. Bob needs access to the project code repository, but should not be able to modify the production deployment scripts or view payroll data.

The sysadmin logs into the server as root. They first create Bob’s user account and add him to the 'developers' group. Then, they ensure the project files are owned by the group 'developers' and have group permissions set appropriately. A common command sequence is: - 'chgrp developers /var/www/project' to set the project directory’s group to developers. - 'chmod g+rwx /var/www/project' to give the developers group read, write, and execute permissions on the project directory. - 'chmod g-w /var/www/project/deploy.sh' to remove write permission specifically on the deploy script, so Bob cannot accidentally (or maliciously) change it. - 'chown root:root /var/www/project/payroll.csv' to restrict payroll data to root only, then set 'chmod 600' on it.

Next, the sysadmin needs to make sure Bob can run a custom tool that must be executed as root. This is where setuid comes in. They create a small wrapper script, ensure it is owned by root, and set the setuid bit with 'chmod u+s /usr/local/bin/acme-tool'. Now, when Bob runs the tool, it executes with root privileges, but Bob never gets a root shell.

Another common task involves the shared team directory. The sysadmin wants new files created by developers to be automatically accessible by the whole group. They set the setgid bit on the team directory: 'chmod g+s /team/project'. Now, if Bob creates a file there, its group automatically becomes 'developers', not Bob’s personal group.

The sticky bit appears when dealing with shared temp directories. The sysadmin might create a shared upload folder for customer invoices: 'mkdir /shared/incoming && chmod 1777 /shared/incoming'. This allows everyone to upload a file, but only the person who uploaded an invoice can delete it. This prevents someone from maliciously deleting another customer’s pending invoice.

Permissions issues cause the most common support tickets. A user cannot save a file. The sysadmin runs 'ls -la' to check permissions, then uses 'stat' to see detailed ownership. They fix it with 'chown' or 'chmod'. They may also run 'find / -type f -perm /6000' to locate all setuid and setgid programs for a security audit, ensuring none are installed that should not be.

Finally, automation scripts use these commands. A backup script must ensure all logs are readable by the backup user. The sysadmin might use a cron job that runs 'chmod o+r /var/log/app*.log' every hour. They rely on umask settings in profile files so that every new log file is created with the correct permissions from the start.

All these actions are done daily, often via orchestrated playbooks (like Ansible) or simple shell scripts. Understanding exactly what each permission does is not just exam trivia — it directly prevents security breaches and application failures.