💾 Archived View for yujiri.xyz › software › guide › unix-permission.gmi captured on 2024-07-09 at 00:08:02. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Learn programming for good instead of profit
written 2023-06-03
Unix was designed in an era where computers were mostly found at universities and corporations where they were shared by multiple users, not personal household belongings, so it was designed with a permission system to prevent different users from overwriting each other's files. This system seems strange and pointless in our era where most computers *are* personal belongings, but it's still in place on modern Unix-derived operating systems, so it's important to know how it works.
Each file has 3 simple permissions (also called its 'mode'): read, write, and execute (run). By default, files you own will have read and write permission enabled for your user, but not execute. This doesn't really stop you from executing them because since you own them, you can change their permissions at will. Presumably the lack of execute permission is just a mechanism to prevent you from accidentally executing things that aren't programs.
Folders will have all three permissions enabled for their owner. What does it mean to execute a folder, you wonder? Good question. It means that you can access the files inside it. If you don't have execute permission on a folder, you can see what it contains (if you have read permission) and can create new things inside it (if you have write permission), but can't read or modify the things inside it, even if you have read and write permission on them.
Another nuance you should be aware of is that you do *not* need write permission on a file to delete it. You need write permission *on the folder that contains it*. This makes sense if you know that deleting a file doesn't actually change the file on disk, it changes the folder's list of contents.
Each file can have each of the 3 permissions on or off separately for 3 categories of users: the user that owns the file, the *group* that owns the file, and all other users. What's a group, you wonder?
Unix has the concept of "groups" of users that can share permissions. Every file has both a user owner and a group owner. One possible use case is to have a file that you can read and write, some other users can read but not write, and other users can't even read it.
Each user account also has a group named after itself that includes only itself. By default, everything you create is owned by your user and group.
Groups are often used to control specific permissions. For example, you might have a group called `audio` that owns some virtual files in `/dev` representing audio devices. Your user account will be in this group, which lets you play sound.
The list of user and group accounts are stored in `/etc/passwd` and `/etc/group`.
All Unix systems have a user account called 'root' which is like the administrator on Windows. root has all permissions on everything (that is, it's not even subject to the permission system), and system files like installed programs are owned by root.
root is also called 'the superuser'.
A file's permissions inculde two other flags called setuid and setgid (set user/group ID). If you have execute permission on a file owned by another user, and that file has the setuid flag enabled, then when you execute it, it'll run with the permissions of its owner instead of with your own permissions. This is how Linux distributions accomplish things like letting the user install packages, which requires writing to files and folders owned by root. Typically there's a program called `sudo` (stands for 'superuser do'), which is owned by root but executable for your user account, and has setuid. You use `sudo` to run other commands. It'll ask you for your password and then run the command you give it as root.
The setgid flag works the same way, but gives you the permissions of the group that owns the program instead of the user that owns it.
This is the last permission-related flag a file or folder can have. It does nothing on a normal file. On a folder, it changes the rules about deletion: it makes it so that to delete a file inside the folder, you have to own the file, not just have write permission to the folder. The sticky bit was presumably created back in the day to let users share a folder without them being able to delete each others' stuff. The only place it's commonly used today is the `/tmp` folder, which contains temporary things and is writable for all users.
User accounts aren't just used for actual users. A Unix-like system will have a lot of "user accounts" that are used only for specific programs. For example, the program `cron` (which is used to run commands in the background at regular intervals such as every day) might have its own user account. The `cron` program runs with the permission of the `cron` user, but nothing else uses it. The cron user owns only the files used by that program.