Users, Groups, and Permissions

Linux FoundationsLesson 5 of 960 minutesLessonBuilds on: Filesystem LabNo lab next

Learning objectives

By the end of this lesson

• Connect the current user and group identities to file ownership.
• Read type and owner/group/other permission bits.
• Predict and verify one controlled access denial and restoration.
• Distinguish permission mode, ownership, and temporary administrative authority.

The question: why is this access allowed or denied?

Permissions are Linux’s answer to a very practical problem. Lots of processes share one system, and they shouldn’t all be able to read or change the same things. So the kernel makes an access decision for one specific request, weighing the process’s identity, the object’s ownership, the operation being asked for, and the object’s permission mode.

The mode is not a vague security rating. It’s a compact set of rules covering three identity classes: the object’s owner, members of the object’s group, and other users. Linux picks the class that applies to the caller and then checks the requested operation against that class’s bits alone (just the one class, and not a helpful combination of several). It will not normally patch a missing owner permission with one borrowed from the other class, however convenient that would be.

Create a disposable target:

mkdir -p ~/underdunn-course/exercises/permissions
cd ~/underdunn-course/exercises/permissions
printf 'course evidence\n' > evidence.txt

Now establish who you’re acting as, and what the target looks like:

id
ls -l evidence.txt
stat -c 'mode=%a owner=%U group=%G' evidence.txt

Typical evidence begins like this:

-rw-rw-r-- 1 student student ... evidence.txt
mode=664 owner=student group=student

Your default mode may well be 644 rather than 664. Use the mode your command shows when comparing the changes below.

Read the permission string

How to read a Linux permission string

-rw-r--r--

regular fileowner
6group
4others
4

chmod 644 file

For -rw-r--r--:

• - identifies a regular file.
• rw- describes owner access.
• r-- describes group access.
• r-- describes everyone else.

r, w, and x mean read, write, and execute. On a directory those same bits control listing names, changing entries, and traversing, so their effect is not the same as on a regular file at all.

On a regular file, read lets you read bytes, write lets you change them, and execute lets you ask Linux to run the file as a program. Execute permission still doesn’t make arbitrary contents runnable, because the kernel also needs either a recognized executable format or an interpreter directive at the top of the file.

Directories shift the meaning, because a directory holds name-to-object mappings. Read lets you list those names, and write lets you create, remove, or rename entries when the surrounding permissions cooperate. Execute permits traversal, which means using a name inside the directory as part of a path. So a directory can be listable but not traversable, or traversable without allowing a full listing. That feels strange right up until you notice “read the list” and “follow this known name through” really are two different operations, so they need separate permission checks.

Numeric modes encode each triplet with read as 4, write as 2, and execute as 1, and adding the enabled values gives you one digit per class. So 6 means read plus write, 4 means read only, and 0 means nothing at all. That makes 640 owner read and write, group read, and nothing for everyone else. The number is just another spelling of the symbolic bits (it is not a second permission system).

Predict a controlled denial

Write this prediction down before you change anything:

If I remove every read bit, will cat evidence.txt still print the contents when I am the owner?

Change only the read bits:

chmod a-r evidence.txt
stat -c 'mode=%a owner=%U group=%G' evidence.txt
cat evidence.txt

cat should come back with Permission denied, and I’d check the exact wording. Notice the owner identity never changed, and only the mode did. That supports one bounded conclusion: ownership on its own does not guarantee access when the relevant mode bit is missing.

Put the known state back right away:

chmod u=rw,g=r,o=r evidence.txt
cat evidence.txt
stat -c 'mode=%a owner=%U group=%G' evidence.txt

Expected content and mode:

course evidence
mode=644 owner=student group=student

Change one permission

Predict the symbolic and numeric difference after adding owner execute permission:

chmod u+x evidence.txt
ls -l evidence.txt
stat -c 'mode=%a' evidence.txt

The owner triplet becomes rwx, and the numeric mode becomes 744. The text file has not become a valid program just because the access request would now be permitted.

Restore 644:

chmod 644 evidence.txt

Ownership and administrative authority

chown changes ownership and chmod changes mode bits, and they answer genuinely different questions. Don’t use sudo chown anywhere in this exercise.

sudo asks Linux to run one command with administrative authority, after it checks policy and authentication. It is not a general-purpose repair prefix, however often it probably gets used as one. Before you reach for sudo, you should be able to name the command, the target, the state change you intend, and how you’d get back.

Administrative authority can bypass ordinary permission checks, making it harder to see which one caused the original failure. If a command fails as your user and succeeds under sudo, you’ve shown that authority changed the outcome. You have not shown that running it elevated is the right long-term answer. So observe the identity and the mode first, and escalate only when the task genuinely needs a system-wide change.

Coreutils file permissions describes how the owner, group, and other classes apply. Look up the selection rule before assuming their permissions are added together.

Practice: check a second file

Create second.txt in the same directory. Set it to owner read and write only (mode 600), predict both the ls -l string and the numeric mode, and then check both in the output. Put it back to 644 when you’re done.

Mode 600 should appear as -rw-------; restoring 644 gives -rw-r--r--. If the mode differs, check the filename and the chmod command.

Common failures and recovery

• cat still works after you removed read permission: confirm the mode with stat, and check you aren’t running the exercise as root.
• You applied the wrong numeric mode: restore it exactly with chmod 644 filename.
• The file has gone missing: go back to the named exercise directory and run the three-line setup again.
• You changed a directory by accident: stop there. Run pwd and ls -ld target before any further chmod.
• You’re no longer sure how to get back: remove only ~/underdunn-course/exercises/permissions, recreate it, and start again from the baseline.

You’re ready to move on when you can explain an access result using three things: the acting identity, the target’s ownership, and the mode triplet that applied.

Next we’ll pin down one exact running process and control it, using the same observe-before-you-change discipline.

Check your understanding

Knowledge check

Question 1 of 2

You own a file whose mode is 0040. With ordinary permission checks, which bits govern your read access?

The owner bits aloneThe most permissive classThe union of all classes

Check answer