Users, Groups and Why Permissions Exist

Part I · Module 5 · Chapter 5.1 · Users, Groups and Why Permissions Exist

1. The Problem Permissions Solve

A laptop you alone use does not obviously need permissions. A machine that forty engineers share does.

On a shared machine, several things have to be true at once:

• your files are yours, and a colleague cannot overwrite them by accident;
• some files genuinely need to be shared with your team and not with everyone;
• the system's own programs and settings cannot be modified by an ordinary user, deliberately or otherwise;
• all of that has to work without anybody asking permission from a person each time.

Linux answers this with one mechanism, applied uniformly to every file and directory. Chapter 2.5 showed you where the answer is recorded — the rw-r--r-- field in a long listing. This chapter is the rule that reads it.

2. Who the System Thinks You Are

Chapter 1.4 ran these two commands for orientation. Now they carry weight.

$ whoami
engineer

$ id
uid=1001(engineer) gid=1001(engineer) groups=1001(engineer),2000(design),2001(verif)

Three things in that id output:

uid=1001(engineer) — your user id. The number is what the system actually uses; the name is a convenience for people. Every file you create will record 1001 as its owner.

gid=1001(engineer) — your primary group. When you create a file, this is the group it gets.

groups=... — every group you belong to. Here that is three: a personal group, design, and verif.

The list form, if that is all you want:

$ groups
engineer design verif

3. Groups: Sharing Without Sharing With Everyone

A group is a named set of users. That is the whole idea.

Its purpose is the middle case. Without groups there would be only two settings — mine and everyone's — and neither fits the common situation of wanting a team to share work while keeping it from the rest of a large machine.

engineer  is in:  engineer (personal),  design,  verif
priya     is in:  priya    (personal),  design
sam       is in:  sam      (personal),           verif

A file whose group is design is accessible to engineer and priya on the group's terms, and to sam only on the everyone-else terms. One setting, the right three people.

Two properties to carry:

You can be in many groups at once. All of them count — §5 shows how.

Groups are created by administrators, not by you. On a shared machine you join the groups your project needs, through whoever runs it. You cannot add yourself.

4. The Three Categories

Every file and directory records one owner and one group. Chapter 2.5 showed both:

$ ls -l shared_notes.txt
-rw-rw-r-- 1 engineer design 8192 Mar 24 11:05 shared_notes.txt

engineer owns it; its group is design.

Against those two facts, any person falls into exactly one of three categories:

The letters u, g and o matter — Chapter 5.3 uses them to change permissions, and u meaning user rather than owner is a small inconsistency worth absorbing now.

5. The Rule: Exactly One Category Applies

Here is the property almost everybody gets wrong at first.

Permissions do not add up. You do not get the owner's rights plus the group's rights. The system asks three questions in a fixed order, stops at the first one that matches, and uses that category's permissions and nothing else.

Work it through on a real line:

$ ls -l report.txt
-rw-r--r-- 1 engineer design 4096 Mar 24 09:30 report.txt

• You are engineer. Question 1 matches. You get the owner's permissions: read and write. Stop.
• You are priya, who is in design. Question 1 does not match; question 2 does. You get the group's: read only.
• You are sam, in neither. Questions 1 and 2 fail. You get everyone else's: read only.

6. Why Permission denied Happens

Every Permission denied you have seen in this course is this rule saying no.

$ cd /root
bash: cd: /root: Permission denied

$ rm /etc/os-release
rm: cannot remove '/etc/os-release': Permission denied

$ mkdir /usr/local/mytool
mkdir: cannot create directory '/usr/local/mytool': Permission denied

Three different commands, one mechanism. In each case the kernel checked which category you fall into for that file or directory, looked at that category's permissions, and found the operation not allowed.

The useful reframing: Permission denied is an answer, not a malfunction. It tells you the system is working and that you are asking for something outside what your account has been granted. The question to ask next is not "how do I get around this" but "which category am I in here, and is that right?" — and Chapter 2.5's ls -l answers it.

$ ls -ld /root
drwx------ 8 root root 4096 Mar 20 08:00 /root

Owner root, and the group and everyone-else sets are empty. You are not root, so you fall into everyone else, who may do nothing. The refusal was correct and completely predictable.

7. The Superuser

One account is exempt.

root, the superuser, bypasses these checks. It can read, change and delete anything on the machine. That exemption exists because somebody has to be able to install software, manage accounts and repair things, and no permission setting could grant that cleanly.

Three practical points for now:

You are almost certainly not root, and on a shared engineering machine you will not be. That is correct and not a limitation to resent.

Commands that ask for administrative rights exist, and you will see them in other people's instructions. Using them belongs to system administration rather than to this course, and running one you do not understand on a shared machine is a genuinely bad idea.

Permission denied on something that is not yours is usually the end of the matter, not an obstacle to route around. The right move is to ask whoever owns the area — a point Chapter 3.3 already made about deletion.

8. What You Can Control

The scope of this module, stated so the next chapters have a shape:

Most of that is yours. The two exceptions — changing an owner, and joining a group — are deliberately outside your reach, for the same reason the rule exists at all.

9. Why This Matters in Engineering Work

Three situations, no semiconductor knowledge required.

Shared project areas. A team working in one directory needs files readable and often writable by the group, and not by the rest of the machine. That is precisely the middle category, and Chapter 5.4 is how it is set up. The alternative — everyone emailing copies around — produces the problem the group mechanism exists to prevent.

Output somebody else cannot read. You run a job, it writes results, and a colleague reports they cannot open them. Nothing is broken: the files were created with permissions that exclude them. Chapter 5.6 explains why that happens by default and how to change it.

Knowing when to stop. A permission error on a system directory means the answer is "ask an administrator", and recognising that immediately saves the half-hour otherwise spent trying to force it.

Part II works almost entirely on shared machines, where every one of these is routine.

10. Practice

Use this listing for the questions:

-rw-r--r--  1 engineer engineer  4096 Mar 24 09:30 private_notes.txt
-rw-rw-r--  1 engineer design    8192 Mar 24 11:05 shared_notes.txt
-r--rw-r--  1 engineer design    2048 Mar 24 11:30 odd.txt
drwx------  8 root     root      4096 Mar 20 08:00 /root

And these people: engineer (groups: engineer, design, verif), priya (groups: priya, design), sam (groups: sam, verif).

Question 1. Which command tells you your user id, primary group and every group you belong to?

Question 2. For shared_notes.txt, which category does each of the three people fall into?

Question 3. Can priya write to shared_notes.txt? Can sam? Explain each using the three-question rule.

Question 4. odd.txt gives the owner read-only and the group read-and-write. Can engineer write to it? Explain why the group setting does not help.

Question 5. Explain in one sentence why permissions do not accumulate, and what the system does instead.

Question 6. cd /root reports Permission denied. Using the listing, say exactly which category you are in and what that category is allowed to do.

Question 7. Why is Permission denied better described as an answer than as a failure?

Question 8. Which two of the following can you change yourself: a file's permissions, a file's group, a file's owner, which groups you belong to?

11. Remember

• Permissions exist so that one machine can serve many people without anyone asking a human for approval.
• The kernel enforces them, at the moment of every request, so no program can ignore them.
• id and groups tell you who the system thinks you are — your user id, your primary group, and every group you are in.
• A group is a named set of users, and it exists for the middle case: sharing with a team but not with everybody.
• Every file records one owner and one group. Against those, you are the owner, in the group, or everyone else.
• Exactly one category applies. The system asks owner, then group, then everyone else, and stops at the first match — so permissions never accumulate.
• That is why an owner can have fewer rights than the group on the same file, and why it is not a mistake.
• Permission denied is the rule working, not a malfunction. ls -l tells you which category you were in.
• root bypasses all of it, which is why you are not root on a shared machine.

The next chapter reads the ten characters themselves — including the part that is genuinely counter-intuitive, where the same three letters mean something different on a directory than they do on a file.