Your Computer Has Users — Even When Only You Use It
If you are the only person who uses your computer, it is tempting to think that the idea of "users" does not really matter.
You switch it on. You log in. You use it.
Surely there is just you.
But look inside almost any modern operating system and you discover something rather different.
Your computer may have many users and groups, even though only one human being normally sits in front of it.
Some belong to real people. Others exist for software, services and administration. Each may be allowed to see, modify or run different things.
This is not simply an organisational convenience.
It is one of the foundations of computer security.
And Linux gives us an unusually good opportunity to investigate how it works.
Start With the Simplest Question: Who Am I?
Open a Linux terminal and type:
whoami
You might see something such as:
philip
That appears straightforward enough.
But now try:
id
You may see something similar to:
uid=1000(philip) gid=1000(philip) groups=1000(philip),27(sudo),100(users)
Suddenly there is rather more going on.
Linux does not fundamentally identify you by the word "philip". Internally, users and groups are associated with numerical identifiers.
A user has a UID — a User ID.
A group has a GID — a Group ID.
The names simply make those numbers easier for humans to understand.
Already we have moved beyond the idea that an operating system simply asks for a username and password when it starts.
The operating system is continually asking questions such as:
Who is trying to open this file?
Which groups do they belong to?
Are they allowed to modify it?
Are they allowed to run this program?
Should this process be allowed access to that directory?
Does this user have administrative privileges?
Those checks happen constantly.
You Are Probably Not the Only User
On many Linux systems, you can inspect the user database with:
cat /etc/passwd
Do not be surprised if the result is much longer than expected.
You may find accounts with names connected to services, system processes and applications.
That does not mean dozens of people have secretly been using your computer.
Many of these are system or service accounts.
Linux deliberately allows services to operate as different users because giving every program complete control over the machine would be extremely dangerous.
Imagine a web server.
Does the software serving a website really need permission to edit every personal document on the computer?
Normally, no.
So the operating system can run it with an identity that has only the permissions it actually needs.
This illustrates one of the most important principles in computer security:
Give a user or process only the access it requires.
This is often called the principle of least privilege.
Why Have Different Users at All?
Suppose a computer is shared by three people.
Alice should be able to open Alice's files.
Ben should be able to open Ben's files.
Charlie should be able to open Charlie's files.
There may also be a shared project folder that all three can use.
But none of them should automatically have permission to alter important operating-system files.
Without an access-control system, separating all of this would be extremely difficult.
User accounts provide one layer of that separation.
Groups provide another.
Creating a New Linux User
If you have a Linux machine that you are happy to experiment with — perhaps a Raspberry Pi, spare computer or virtual machine — try creating another user.
On Ubuntu and many Debian-based systems, you can use:
sudo adduser alice
The system will ask you to supply information and choose a password.
On systems using the more general useradd command, you might instead use:
sudo useradd -m alice
The exact administration commands vary slightly between Linux distributions, which is itself a useful reminder that "Linux" is not one single operating system installation.
Now check the account:
id alice
Linux should report Alice's user ID, primary group and any additional groups to which she belongs.
At this point Alice is more than a name on a login screen.
She has become an identity that the operating system can use when making security decisions.
Users Are Useful — Groups Make Them Powerful
Suppose Alice, Ben and Charlie are working on the same programming project.
We could individually configure permissions for each person.
But that quickly becomes awkward.
Instead, we can create a group.
For example:
sudo groupadd programmers
Then add Alice:
sudo usermod -aG programmers alice
We could add Ben and Charlie in the same way.
Now permissions can be granted to the group programmers instead of having to be configured separately for every person.
This is much closer to the way access control works in organisations.
A school might have groups representing:
teachers
students
science_staff
administrators
IT_support
A business might have:
accounts
management
design
marketing
development
HR
When somebody joins or leaves a department, their group membership can be changed rather than thousands of individual files being reconfigured.
Who Owns This File?
Now create an ordinary file:
touch experiment.txt
Then examine it with:
ls -l experiment.txt
You might see:
-rw-r--r-- 1 philip philip 0 Sep 21 14:00 experiment.txt
There is a great deal of information packed into that single line.
Part of it tells us who owns the file.
In this example:
philip philip
The first philip is the owner.
The second philip is the group associated with the file.
But the mysterious sequence at the beginning is particularly interesting:
-rw-r--r--
This describes the permissions.
Decoding Linux Permissions
Ignore the first character for the moment and separate the remaining characters into three groups:
rw- r-- r--
They represent permissions for:
owner
group
others
Each section can contain three letters:
r = read
w = write
x = execute
So:
rw-
means that the owner can read and write the file but does not have execute permission.
The group has:
r--
so members of the group can read it but not modify it.
Everyone else also has:
r--
so they can read the file but cannot change it.
The operating system can therefore make different decisions depending on who is requesting access.
Read, Write and Execute
For files, the meanings are fairly intuitive.
Read (r) means the contents can be viewed.
Write (w) means the contents can be changed.
Execute (x) means the file can be run as a program or script, provided it is otherwise executable.
Directories are slightly more interesting.
For a directory:
read permission allows its contents to be listed;
write permission allows files and directories to be created or deleted within it;
execute permission allows the directory to be entered or traversed.
That distinction is worth experimenting with because directory permissions often surprise students.
Change the Permissions Yourself
Linux provides the chmod command for changing permissions.
For example:
chmod u+x experiment.txt
This adds execute permission for the user who owns the file.
The u means user or owner.
We can also use:
g
for group
and:
o
for others.
So:
chmod o-r experiment.txt
removes read permission from everybody classified as "other".
You can combine several changes:
chmod u+rw,g+r,o-rwx experiment.txt
Then use:
ls -l experiment.txt
again and see what changed.
This is one of those computing topics that becomes much clearer when students actually change permissions rather than simply memorising definitions.
Why Do People Write Permissions as Numbers?
You may also encounter commands such as:
chmod 750 program.sh
This looks rather mysterious until you realise that each permission can be represented by a number.
read = 4
write = 2
execute = 1
Add together the permissions you want.
So:
7 = 4 + 2 + 1 = read + write + execute
5 = 4 + 1 = read + execute
0 = no permissions
Therefore:
750
means:
owner = 7 = rwx
group = 5 = r-x
others = 0 = ---
So the resulting permissions are:
rwxr-x---
This numerical form is extremely common in Linux administration.
It is not a different permission system. It is simply another way of expressing the same permissions.
Ownership Matters Too
Permissions make little sense unless the operating system also knows who owns the file.
Linux provides chown for changing ownership.
For example:
sudo chown alice experiment.txt
would make Alice the owner.
We can change both owner and group:
sudo chown alice experiment.txt
Now Alice owns the file and the associated group is programmers.
Imagine that the file contained the source code for a shared programming project.
We could then give Alice full control, allow other programmers to read and modify it, and prevent everybody else from accessing it.
That is access control in action.
A Better Practical: Build a Shared Project Area
Rather than experimenting with a single file, we can make the activity more realistic.
Create a directory:
sudo mkdir /projects
Create a project group:
sudo groupadd projectteam
Add two test users:
sudo adduser alice
sudo adduser ben
Then add both users to the group:
sudo usermod -aG projectteam alice
sudo usermod -aG projectteam ben
Change the group ownership of the project directory:
sudo chown root /projects
Then set suitable permissions:
sudo chmod 770 /projects
The permissions 770 mean:
owner: read, write and execute
group: read, write and execute
others: no access
Now Alice and Ben can both work in the directory because they belong to projectteam.
Another ordinary user should not be able to enter it.
We have effectively created a very small access-control system.
Try to Break Your Own Security
This is where the experiment becomes much more interesting.
Rather than simply checking that something works, deliberately try to make it fail.
Log in as Alice.
Create a file.
Try to modify it as Ben.
Change the group permissions.
Try again.
Remove Ben from the project group.
Try again.
Create another user who is not a member of the group.
Can that user enter the directory?
If not, why not?
Students should start thinking about security as a set of rules that can be tested rather than as a collection of definitions to memorise.
The Most Powerful User: root
Linux has a special administrative account traditionally called:
root
The root user has enormous authority over the system.
It can access files, change ownership, install software, create users, terminate processes and alter the operating system.
That is precisely why normal day-to-day computing should not normally be performed as root.
Instead, many Linux distributions use sudo.
For example:
sudo apt update
or:
sudo adduser alice
The user temporarily requests permission to perform an administrative operation.
This is another example of least privilege.
You do not need unlimited administrative power merely to browse the web, write a document or run Python.
You elevate your privileges only when necessary.
That is a much safer approach.
Why Malware Makes This Important
Imagine downloading a malicious program.
If that program is running with unrestricted administrator privileges, it could potentially change almost anything on the system.
If it is running as a restricted user, the damage it can cause may be limited by the permissions available to that account.
Permissions are not a complete defence against malware, but they form an important part of a layered security model.
This is one reason modern operating systems are increasingly reluctant to let ordinary applications run permanently with administrator privileges.
Windows Does This Too
It is easy to assume that users, groups and permissions are mainly a Linux idea because Linux makes them particularly visible.
Windows has similar concepts.
Open Windows Settings and you will find user accounts.
A Windows account might be:
a local account;
a Microsoft-connected account;
a standard user;
an administrator.
Windows also uses groups.
Two important examples are:
Users
and:
Administrators
A standard account should not automatically have unrestricted control over the system.
When Windows displays a User Account Control message asking whether an application may make changes to your device, you are seeing part of this security structure in action.
Linux Permissions and Windows Permissions Are Not Identical
The traditional Linux model is beautifully simple.
For each file we have permissions associated with:
owner
group
others
Windows, particularly when using NTFS, can use more detailed Access Control Lists or ACLs.
A file might grant different permissions to several individual users and groups.
For example:
Alice: Full control
Project Team: Modify
Teachers: Read
Students: Read
Guest: No access
Linux can also use ACLs, so the real systems are more sophisticated than the simple owner-group-other model suggests.
But the traditional Linux permission system remains an excellent way of understanding the fundamental idea.
The operating system needs to answer:
Who is requesting access, and what are they permitted to do?
A Useful Windows Comparison
Find a file in Windows.
Right-click it and select:
Properties -> Security
You should see users and groups that have permissions associated with that file.
Depending on the file and system configuration, permissions may include:
Full control
Modify
Read & execute
Read
Write
Now compare that with:
ls -l
on Linux.
The interfaces look completely different, but the underlying problem is much the same.
We have:
an object
a user
a set of permitted actions
and an operating system responsible for enforcing the rules.
A Command-Line Windows Investigation
Students who have Windows can also investigate accounts using PowerShell or Command Prompt.
For example:
whoami
works in Windows too.
Try:
whoami /groups
and you can see groups associated with the current security identity.
Another useful command is:
net user
which lists local user accounts.
To investigate file permissions from the command line, Windows provides tools including:
icacls
For example:
icacls example.txt
The result looks rather different from Linux ls -l, but the purpose is related: examining who can do what with a particular file.
What About a Personal Computer?
You might reasonably ask why any of this matters on a computer used by just one person.
There are several reasons.
Your ordinary account should not necessarily have unrestricted administrator access all the time.
Background services do not need access to every personal file.
Applications can operate with limited privileges.
Malware may be restricted by account permissions.
Different services can be isolated from one another.
Sensitive files can be protected.
Network servers can limit which accounts may access resources.
So even a single-user computer is actually a multi-user security environment.
The "users" do not all have to be human.
A Raspberry Pi Makes an Excellent Demonstration
This is an especially good experiment for a Raspberry Pi or spare Linux machine.
You can create several imaginary users without interfering with a student's main computer.
For example:
alice
ben
teacher
student
webserver
You can then create directories and decide who should have access.
Perhaps:
/home/alice
should belong only to Alice.
/schoolwork
might be available to the student and teacher.
/markscheme
might be accessible only to the teacher.
/website
might need to be readable by a web-server account.
Suddenly users and permissions stop being abstract concepts.
They become solutions to real computing problems.
A Challenge for A-Level Students
Try designing a Linux permission system for a fictional school.
Create groups for:
teachers
students
science
computing
administrators
Then create directories representing:
student work
teacher resources
computer-science projects
examination papers
shared resources
Decide which groups should have:
read
write
execute
permissions.
Then implement your design.
Afterwards, test it by logging in as different users.
The important part is not simply getting the commands right.
You should be able to justify every access decision.
Why should a student be able to read one directory but not another?
Why should a teacher be able to modify a file?
Why should an administrator have greater access?
Why should a web server have less?
Those are exactly the sorts of questions real system administrators and cybersecurity professionals have to answer.
One Important Warning
Do these experiments on a machine where changing accounts and permissions will not damage important work.
A Raspberry Pi, virtual machine or spare Linux installation is ideal.
Be particularly careful when using:
sudo
chmod
and:
chown
on important system directories.
Changing permissions recursively on the wrong directory can make a Linux installation unusable.
Learning about security is much more enjoyable when the computer still boots afterwards.
From Examination Topic to Real Operating System
Students often meet access rights as a short section in a computing specification.
They learn phrases such as:
authentication
user account
administrator
file permissions
access rights
And then move on.
But these are not merely examination vocabulary.
They describe mechanisms operating underneath almost everything you do on a modern computer.
When you save a file, launch a program, install software or access something across a network, the operating system may need to decide whether your current identity has permission to perform that operation.
Linux simply makes the machinery unusually easy to see.
The Bigger Lesson
One of the things I like about teaching computing through Linux is that concepts which can seem rather theoretical suddenly become visible.
Instead of merely telling a student that operating systems control access to resources, we can create two users and prove it.
Instead of defining file permissions, we can change them and watch access disappear.
Instead of describing groups, we can create one and use it to control a shared project directory.
And instead of vaguely saying that administrators have greater privileges, we can see precisely what happens when a command requires sudo.
That is far more memorable than simply learning a definition.
Your computer may sit on your desk and be used by only one person.
But inside the operating system is an entire system of identities, ownership, groups and permissions constantly deciding:
Who are you?
What belongs to you?
What are you allowed to do?
Once you understand those questions, you have started to understand not just Linux, but one of the fundamental ideas behind operating systems and computer security.
No comments:
Post a Comment