File permissions, ownership and ACLs

Why this matters

CompTIA teaches permissions in chapter 3, immediately after users and groups, and that placement is a judgement worth copying. Permissions are not a security speciality you get to later — they are the reason a script will not run, a web server returns 403, a backup misses half a directory, and a log file cannot be written. You cannot debug any of those without them.

The model is small enough to learn in one sitting and precise enough to reason about exactly. That combination is rare and worth the effort.

The lesson

Reading the permission string

-rwxr-xr--  1 alice developers  4096 Sep  9 10:15 deploy.sh

The first character is the type: - a regular file, d a directory, l a symlink, b a block device, c a character device.

The next nine are three groups of three:

The kernel checks these in order and stops at the first match. If you are the owner, only the owner bits apply — even if the group bits are more permissive. An owner with r-- on a file whose group has rw- cannot write to it, and being in that group does not help. This surprises people constantly.

What the bits mean on a directory

Same three letters, different meanings, and this is where most confusion lives:

Three consequences that explain real behaviour:

• x without r on a directory means you can use a full path through it but cannot list it. This is how /home is often configured.
• r without x lets you see the names and nothing else — ls works, opening anything fails.
• Deleting a file depends on the directory's permissions, not the file's. You can delete a file you have no write access to, provided you can write to the directory containing it. That is the single most counter-intuitive rule here, and it is what the sticky bit exists to fix.

Octal and symbolic notation

Each bit has a value: r=4, w=2, x=1. Add them per group.

chmod 644 report.txt        # octal: set exactly
chmod 755 script.sh
chmod u+x script.sh         # symbolic: add execute for the user/owner
chmod g-w file              # remove write from the group
chmod o= file               # remove everything from others
chmod a+r file              # add read for all
chmod -R 755 /var/www       # recurse
chmod u=rw,g=r,o= file      # set each class explicitly

Octal sets, symbolic adjusts. chmod 644 overwrites whatever was there; chmod u+x changes one bit and leaves the rest. When you are modifying a file whose current permissions you have not checked, symbolic is the safer choice.

A recursive chmod -R 755 on a document tree makes every file executable, which is untidy and occasionally dangerous. The correct idiom separates them:

find /var/www -type d -exec chmod 755 {} \;
find /var/www -type f -exec chmod 644 {} \;

Ownership

chown alice file                 # change owner
chown alice:developers file      # owner and group
chown :developers file           # group only
chown -R alice:alice /home/alice # recurse
chgrp developers file            # group only, dedicated command

Only root can give a file away to another user. A normal user can change a file's group, but only to a group they belong to.

umask

New files do not get their permissions from nowhere: the system starts from a base and removes the bits in your umask.

• Base for files: 666 (rw-rw-rw-) — never executable by default, which is deliberate
• Base for directories: 777

umask           # show, typically 0022
umask 077       # new files 600, new directories 700 — private

With the common umask of 022: files become 666 − 022 = 644, directories 777 − 022 = 755. With 077 nothing is readable by anyone else, which is the right setting on a shared machine.

Note it is a mask, not a subtraction, so it can only ever remove permission. A umask cannot make a new file executable.

Special permissions

Three extra bits sit above the usual nine.

setuid (4000) — an executable runs as its owner rather than as the caller. Shows as s in the owner's execute position.

chmod u+s /usr/local/bin/tool
chmod 4755 /usr/local/bin/tool
ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root ... /usr/bin/passwd

This is how passwd writes to /etc/shadow. It is also the most dangerous bit on the system: a setuid-root program with a flaw hands out root. Auditing them is routine:

find / -perm -4000 -type f 2>/dev/null

setgid (2000) — on an executable, run with the group's identity. Far more useful on a directory, where it means new files inherit the directory's group rather than the creator's primary group. That is how a shared project directory stays usable:

chmod 2775 /srv/project
chmod g+s /srv/project

Without it, every file Alice creates belongs to group alice and Bob cannot write to it — the classic shared-folder failure.

Sticky bit (1000) — on a directory, only a file's owner (or root) may delete it, regardless of directory write permission. Shows as t.

chmod +t /shared
ls -ld /tmp
drwxrwxrwt 10 root root ... /tmp

/tmp is world-writable so anyone can create files there; the sticky bit is the only thing stopping anyone deleting everyone else's. It exists precisely to patch the "deletion depends on the directory" rule above.

In four-digit octal the special bits come first: chmod 4755, 2775, 1777.

A capital S or T instead of lowercase means the special bit is set while the underlying execute bit is not — usually a mistake.

Access control lists

Standard permissions allow exactly one owner and one group. When you need "and also Carol, read-only", that model runs out. ACLs extend it.

getfacl report.txt                        # show the ACL
setfacl -m u:carol:r report.txt           # grant carol read
setfacl -m g:auditors:rx /srv/logs        # grant a group
setfacl -x u:carol report.txt             # remove that entry
setfacl -b report.txt                     # strip all ACLs
setfacl -m d:u:carol:rwx /srv/project     # DEFAULT: applies to new files inside
setfacl -R -m u:carol:rX /srv/project     # recurse

A file with an ACL shows a + at the end of its permission string:

-rw-rw-r--+ 1 alice developers 4096 Sep  9 10:15 report.txt

That plus sign is the only visible hint in ls -l, and missing it is why permissions sometimes appear not to match observed behaviour. If access does not make sense, run getfacl.

The d: (default) entries matter for shared directories: they are inherited by newly created files, which is what makes an ACL stick rather than needing to be reapplied.

Immutable and other file attributes

Separate from permissions and ACLs, the filesystem itself carries attributes.

lsattr file                # list attributes
chattr +i /etc/resolv.conf # IMMUTABLE
chattr -i /etc/resolv.conf # remove it
chattr +a /var/log/audit.log  # APPEND ONLY

Immutable (+i) means the file cannot be modified, deleted, renamed or linked to — by anyone, including root. That is the point: it stops a script or a package from overwriting a file you have pinned. It is also the answer to "root gets permission denied and I cannot see why", which is otherwise a genuinely baffling symptom. Check lsattr before assuming the filesystem is corrupt.

Append-only (+a) allows writes only at the end. Existing content cannot be altered, which is exactly what you want for a log you need to trust.

Both require root to set or clear.

On the exam

• Permission checking stops at the first matching class. Owner bits win for the owner even when group bits are more generous.
• Deleting a file depends on the directory's write permission, not the file's. The sticky bit is the fix, and /tmp is the example.
• On a directory: r lists, w creates and deletes, x enters.
• Default umask 022 gives files 644 and directories 755. Know both bases — 666 for files, 777 for directories.
• setgid on a directory makes new files inherit its group. This is the shared-project answer.
• setuid is why passwd works, and find / -perm -4000 is how you audit it.
• A + after the permission string means an ACL is present. Read it with getfacl.
• chattr +i blocks root too, and lsattr is how you discover that.