Users, Groups and Permissions

In this chapter

We'll learn how the OS decides who can do what — users, groups and permissions — read a real Linux permission line, and fix Anna's "Permission denied" the right way instead of running everything as admin.

12–14 min

The Problem in Real Life

Back to this morning's error. On the test server, Anna tried to change BlueTicket's settings file and got: Permission denied: /etc/blueticket/config.json.

A teammate walking past says, "Just use admin rights — then it'll work." John shakes his head. "It will work. That's the problem. Let's understand why it said no first."

"Permission denied" isn't a bug. It's the computer protecting something — find out what before you go around it.

John

"Just Run It as Admin" vs. Understanding Who Is Allowed

The file is protected on purpose

System settings are locked so that a mistake or an attacker can't change them easily.

Who you are decides what you can do

Every action on a computer is done as some user, and the OS checks that user's rights.

Admin for everything is dangerous

Running everything with full rights removes the protection — for your mistakes and for attackers.

Every computer is shared by more than one "someone": you, other people, and many background services. The OS keeps track of them with three ideas:

Users — every person or service that uses the computer has a user account with a name and an ID. Every process runs as a user, and gets that user's rights. On Linux, the all-powerful user is called root; on Windows it's the Administrator. Services often get their own limited users, like a blueticket user that only runs the app.
Groups — a group is a named collection of users, so you can give rights to many people at once. For example, a developers group or a blueticket group. Each file belongs to one owner and one group.
Permissions — rules saying who can do what with each file or directory. Linux uses three permissions: read (r) — look at the contents; write (w) — change it; execute (x) — run it as a program (or, for a directory, enter it). It checks them for three kinds of people: the owner, the file's group, and others (everyone else).

Table — Reading -rw-r--r-- root root config.json

Part	Value	Meaning
Type	-	A normal file (d = directory)
Owner rights	rw-	The owner can read and write
Group rights	r--	The group can only read
Others' rights	r--	Everyone else can only read
Owner	root	The admin user owns it
Group	root	The file belongs to the root group

Table — Ways to fix "Permission denied" — from worst to best

Approach	Works?	Safe?
Run everything as admin / root	Yes	No — removes all protection
chmod 777 (everyone can do anything)	Yes	No — anyone can change or delete it
sudo for this one command only	Yes	Okay, if you know exactly what it does
Give the right group write access	Yes	Yes — least privilege

This whole line is a row — one record

Checking and fixing permissions on Linux

ls -l /etc/blueticket/config.json
# -rw-r--r-- 1 root root 1.2K config.json

sudo chgrp blueticket /etc/blueticket/config.json   # give the file to the blueticket group
sudo chmod g+w /etc/blueticket/config.json          # let that group write to it

ls -l /etc/blueticket/config.json
# -rw-rw-r-- 1 root blueticket 1.2K config.json

sudo is used only for these two changes. After them, people in the blueticket group can edit the file without admin rights.

John runs ls -l on the file. The answer is one line:

-rw-r--r-- 1 root root 1.2K config.json

Reading it from left to right: the first character - means it's a normal file (d would mean directory). Then come three groups of three: rw- for the owner (read and write), r-- for the group (read only), r-- for others (read only). Then the owner — root — and the group — root. Anna isn't root and isn't in the root group, so she's "others": read only. That's exactly why writing failed.

Why not just use admin rights? Using sudo (Linux) or "Run as administrator" (Windows) runs a command with full rights. Doing that for one careful action is sometimes right. But doing everything as admin — or changing the file to 777 (everyone can do everything) — removes the protection completely. One typo could now break the whole server, and any harmful program running as you could change it too.

The right fix is to give exactly the access needed, and no more. John and Anna make the blueticket group the file's group and let that group write to it. The app's user and the developers who manage it are in that group. Everyone else can still only read it. This rule — give the smallest access that does the job — is called least privilege, and it's one of the most important ideas in security (Act 22).

Windows works on the same idea with different tools: standard vs. administrator accounts, a pop-up called UAC that asks before anything gets admin rights, and detailed per-file permission lists called ACLs (Access Control Lists).

Key Takeaway

Every process runs as a user, and the OS checks that user's permissions — read, write and execute for the owner, the group and others — before allowing any action. "Permission denied" means the protection is working; the fix is to grant just the access needed (least privilege), not to run everything as admin.

Why This Matters

Permissions are where operating systems and security meet. On BlueTicket's servers, the app runs as its own limited user so that even if an attacker finds a bug in it, they can't take over the whole machine. Reading a permission line and fixing access properly — instead of giving up and using 777 — is a skill Anna will use on every server she ever touches.

Anna can now say who may touch a file and why. But how does a program actually ask the OS to open that file in the first place — or read a key press, or send data over Wi-Fi? There's one official doorway, and the next chapter walks through it.