Permissions Attach to Processes, Not Files

In one line

Access control in Linux is judged not by "who can read this file" but by "how the credentials this process is holding right now line up with this inode's permission bits". Once you grasp this viewpoint, setgid directories and ACL masks are both naturally understood.

Why this exists

Questions keep coming in saying "I added the user to a group but the permission didn't take effect". The cause is almost always one. Supplementary groups are copied into the process's credentials at login time. A shell that is already running keeps holding the old group list, and file access decisions are made with that list. If you changed the groups, you have to log in again or open a new session.

/etc/passwd holds the name, UID, GID, home, and shell, and all password-related information is separated into /etc/shadow. The reason for the separation is simple — /etc/passwd has to be readable by everyone so that ls -l can turn a UID into a name, but the hash must not be.

The fields of /etc/shadow are separated by colons.

Number	Content
2	Password hash. A leading exclamation mark means locked, an asterisk means password login is not possible
3	Date of last password change (days since 1970-01-01)
4	Minimum days in use
5	Maximum days in use
6	Days of warning before expiry
8	Account expiry date (also in days)

That it is days and not a date comes up often on the exam. What converts it into a human-readable form is chage -l.

How it works

Why a setgid directory is the right answer for a collaboration directory. The group of a newly created file is normally the creator's primary group. If three team members each have a different primary group, files pile up in the shared directory under assorted groups. If you set setgid on the directory, files created inside it inherit the directory's group. A new subdirectory inherits the setgid bit as well, so the whole tree is maintained.

The sticky bit takes back the right to delete. What you need to delete a file is not permission on the file but write permission on the directory. If you open a shared directory as writable to everyone, you can delete other people's files too. With sticky set, only the file's owner, the directory's owner, and root can delete. /tmp is exactly this configuration.

The moment you need an ACL is when there is "an exception for just one person". With the three slots of owner, group, and other, you cannot express "this group gets read, but one audit person gets write". Attaching a named entry instead of creating a new group is what an ACL is.

This is where the mask appears. The mask is the upper limit on permissions for every entry except the owner and other (named users, named groups, and the owning group). The lines getfacl shows with #effective: are exactly the entries trimmed by the mask. And there is a trap — if you run chmod on the file, its group bits are interpreted as the mask, and the ACL you just granted is silently disabled.

You can set a default ACL on a directory. This is not used to judge access to that directory itself; it is inherited as the initial ACL of entries created inside it from then on.

What it looks like in the field

The author's article on file descriptors and inodes sums up this problem in one sentence. Write permission and delete permission on a file are separate, and the incident where someone else's file is deleted in a shared directory comes from exactly there. The standard solution that article presents is chmod 1777 — that is, the sticky bit. Conversely, if you run a shared directory without setgid, the group differs from file to file, and cleanup work that runs chgrp -R in bulk afterward arises periodically.

The most expensive mistake on the account side is leaving out the append option when adding a supplementary group. If you use only usermod -G, the existing supplementary groups are all replaced by the list you specify. If you remove yourself from the sudo group and end up with no root shell either, it becomes a console access problem from then on.

Permission problems that often trip you up in the exam room

The LFCS is a practical exam, so it asks not "can you explain it" but "does your hand remember". There are a few forms that recur in the permissions domain.

Setting a special bit is done by the leading digit of the number.

Bit	Number	On a file	On a directory
setuid	4000	Runs with the owner's privileges	(no meaning)
setgid	2000	Runs with the group's privileges	New files inherit the directory's group
sticky	1000	(no meaning)	Only the owner can delete their own files (/tmp)

A collaboration directory problem is almost always setgid. A requirement like "make it readable and writable by any team member" is solved with chgrp team dir; chmod 2775 dir. Without setgid, new files get the creator's primary group and other team members cannot read them.

For an ACL you have to set the default ACL as well. If you set it only on the files that exist now, it does not apply to files created later.

setfacl -m u:alice:rwx /srv/data          # 지금 있는 것
setfacl -d -m u:alice:rwx /srv/data       # 앞으로 만들어질 것
getfacl /srv/data

If you see a + at the end of the permissions in ls -l, it means an ACL is set. If you miss this, you wander for a long time on "the permissions are right, so why doesn't it work".

umask applies only to what you create from now on. Files that already exist have to be fixed with chmod. Conversely, answering a requirement like "make files created from now on like that too" with chmod is wrong.

When you delete a user, it asks what to do about the home and the mail queue. userdel -r deletes the home directory too. If you do not delete it, then when that UID is reused, the new user ends up owning the old files. So if you are not going to delete it, move the ownership first.

Always verify after you change something. The three lines id 사용자, groups 사용자, and sudo -l -U 사용자 (the placeholder is the user name) reveal most configuration problems.

What you will do in the next lab

First you actually create users and groups. You set up an account by specifying UID, primary group, home, and shell, add supplementary groups, apply a password policy with chage, and read those values directly from /etc/passwd, /etc/group, and /etc/shadow to confirm them. At the end you delete only the account and leave the home, to see an orphan UID come into being. In the following lab you work through octal and symbolic modes, umask, special bits, and ACLs with masks in turn.