Learn › Linux Foundations › Permissions, Ownership and Users
Final test: Chapter 20, Permissions, Ownership and Users. Twenty-five objectives on a real Debian 12 server covering all three parts: ls -l, stat and chmod with letters and numbers, directory modes, umask and the setuid bit, then id, chgrp and chown through exact sudo rules, then getent, useradd, usermod -aG, passwd -S and sudo -u. Fifty minutes, graded from the state of files, accounts and groups and from the commands you run.
This chapter covers the following topics:
This is Part 3 of 3. Part 1 covered Sections 20.1 to 20.6, the mode, and Part 2 covered Sections 20.7 to 20.10, groups and owners. This part covers Sections 20.11 to 20.15: reading the account database, creating an account, giving it a group, reading the state of its password, and running a command as it. It ends in the chapter lab, which covers all fifteen sections.
What you already know: Section 4.4 read the accounts in /etc/passwd and Section 4.5 the groups in /etc/group. Section 7.13 ran a command as another account with sudo -u, and Section 20.9 used the exact sudo rules of this server. This part creates the account webdev with the rules Part 2 printed.
Objectives
After this part you can:
Select Start machine in the adjacent workspace and use its Terminal. The account you create on this practice machine remains for its session. The chapter assessment starts a separate fresh Debian machine and checks file, account and group state and the commands you run. Follow the startup and session-time displays in the workspace.
Five questions before the material. A wrong answer costs nothing: the explanation states the fact and names the section that teaches it.
>>> getent reads a record from the account database through the same lookup every program uses. On this server the database is /etc/passwd, which every account may read, and no password is in it. Section 20.11.
>>> An account is a set of lines in the account files plus a home directory. Only root may write those files, so useradd runs through sudo, and this server allows exactly one useradd line. Section 20.12.
>>> -m makes the home directory, /home/webdev, and copies the files of /etc/skel into it. Without it the account has a home in its record and no directory on disk. Section 20.12.
>>> -G sets the list of supplementary groups, and without -a, append, it replaces the whole list. Every group left out is removed. Section 20.13.
>>> L is locked, P a usable password, NP no password at all. An account useradd creates without a password is locked. Section 20.14.
Section 4.4 read the accounts of this server by printing /etc/passwd with cat. On a larger network, accounts can also come from a directory server. getent, get entries, asks the system for a record through the same lookup every program uses, whatever the source. It takes the name of a database, passwd for accounts or group for groups, and a key, the name to look up. On this server both databases are the files Chapter 4 read. You are in your home directory. Print the record of the account admin:
prompt: admin@server1:~$ answer: getent passwd admin output: admin:x:1000:1000::/home/admin:/bin/bash hint: Section 20.11. The database command, the database passwd, then the name admin.
One line, the seven fields of Section 4.4 separated by colons. The name, then x for a password kept in /etc/shadow, the UID 1000 and the GID of the primary group, 1000. Then an empty comment, the home directory and the login shell.
You are in your home directory. Print the record of the group webteam from the group database, with the database name group and the key webteam:
prompt: admin@server1:~$ answer: getent group webteam output: webteam:x:1100:admin hint: Section 20.11. The database command, the database group, then the name webteam.
The four fields of Section 4.5: the name, x, the GID 1100, and the members, here admin alone. This list is where the supplementary groups of Section 20.7 come from.
Before creating an account, check that its name is free. You are in your home directory. Ask id from Section 7.4 for the record of webdev:
prompt: admin@server1:~$ answer: id webdev output: id: ‘webdev’: no such user hint: Section 7.4. The two-letter record command with the account name webdev after it.
no such user: the name is free. getent passwd webdev answers the same question with no output at all and the exit status 2, which Section 10.4 reads with $?.
useradd creates an account. It writes the account line to /etc/passwd and a password line to /etc/shadow, and on Debian it also creates a group with the same name as the account. -m makes the home directory and copies into it the starting files kept in /etc/skel, and -s sets the login shell. Debian also ships adduser, a program that asks questions and then runs useradd for you; the rules of this server do not include it.
The policy Part 2 printed allows exactly one useradd line. First try the command without sudo. You are in your home directory:
prompt: admin@server1:~$ answer: useradd -m -s /bin/bash webdev output: bash: useradd: command not found hint: Section 20.12. The account command with -m, -s and /bin/bash, then the name webdev, and no sudo in front.
bash did not find useradd at all. It lives in /usr/sbin, the directory of administration programs, and the PATH of an ordinary account (Section 8.7) does not include it. sudo searches its own list, the secure_path Section 7.11 printed, which does. Run by its full path, useradd starts and refuses; the step Errors you will meet shows that message.
{ "caption": "One command, three account files and a home directory. -m made the home and copied /etc/skel into it.", "nodes": [ { "id": "u", "label": "useradd -m", "kind": "command", "col": 0, "row": 1 }, { "id": "p", "label": "/etc/passwd", "kind": "file", "col": 2, "row": 0 }, { "id": "s", "label": "/etc/shadow", "kind": "file", "col": 2, "row": 1 }, { "id": "g", "label": "/etc/group", "kind": "file", "col": 2, "row": 2 }, { "id": "h", "label": "/home/webdev", "kind": "file", "col": 2, "row": 3 } ], "edges": [ { "from": "u", "to": "p", "label": "the account", "kind": "plain", "stage": 1 }, { "from": "u", "to": "s", "label": "a locked password", "kind": "plain", "stage": 2 }, { "from": "u", "to": "g", "label": "the group webdev", "kind": "plain", "stage": 3 }, { "from": "u", "to": "h", "label": "the home", "kind": "plain", "stage": 4 } ] }
You are in your home directory. Create the account webdev with a home directory and bash as its login shell, through sudo, exactly as the rule lists it:
prompt: admin@server1:~$ answer: sudo useradd -m -s /bin/bash webdev output: hint: Section 20.12. sudo, then the account command with -m, -s and /bin/bash, then the name webdev, exactly as sudo -l lists it.
Silent: the account exists. The next three exercises check each thing useradd wrote. It also wrote a line to /etc/gshadow, which holds group passwords, nobody uses here, and only root and the group shadow may read.
You are in your home directory. Print the account record of webdev:
prompt: admin@server1:~$ answer: getent passwd webdev output: webdev:x:1002:1002::/home/webdev:/bin/bash hint: Section 20.11. The database command, the database passwd, then the name webdev.
On this prepared machine, getent passwd webdev reports UID 1002. That number is an observed result, not a rule that useradd always takes the next number after the highest ordinary account. Its defaults and the IDs already allocated determine which free ID is chosen. GID 1002 is the primary group created here. The comment is empty, and the home and shell are the ones requested.
You are in your home directory. Print the group record of webdev:
prompt: admin@server1:~$ answer: getent group webdev output: webdev:x:1002: hint: Section 20.11. The database command, the database group, then the name webdev.
A private group is a group named for one account. On this prepared server, useradd created webdev as the account's primary group. The group record has an empty member list because primary membership is recorded by the GID in webdev's account record, not in that list. This behavior depends on the server's useradd defaults.
You are in your home directory. List the directory /home/webdev itself. The date and time on your screen are the moment you created the account, so they differ from the ones below:
prompt: admin@server1:~$ answer: ls -ld /home/webdev ||| ls -dl /home/webdev ||| ls -ld /home/webdev/ output: drwxr-xr-x 2 webdev webdev 4096 Sep 30 15:05 /home/webdev hint: Section 20.4. The listing command with -l and -d together, then the absolute path /home/webdev.
Owned by webdev and its group, mode 755. useradd sets the mode of a new home from the UMASK line of /etc/login.defs, which is 022 on Debian, so 777 becomes 755 as in Section 20.5.
usermod, modify user, changes an account that exists. -G sets its supplementary groups, and -a, append, keeps the groups it already has and adds the ones named. Without -a, -G replaces the whole list, and every group left out is removed, which takes access away from the account. This server allows exactly one usermod line. You are in your home directory. Add webdev to webteam:
prompt: admin@server1:~$ answer: sudo usermod -aG webteam webdev output: hint: Section 20.13. sudo, then the modify command with -aG, the group webteam, and the account webdev.
Silent. usermod added webdev to the member list of webteam in /etc/group.
You are in your home directory. Print the names of the groups of webdev with id from Section 20.7:
prompt: admin@server1:~$ answer: id -Gn webdev ||| id -nG webdev ||| groups webdev output: webdev webteam hint: Section 20.7. The identity command with -Gn, then the account name webdev.
The primary group first, then webteam. The group database says the same from its side, getent group webteam:
webteam:x:1100:admin,webdevwebdev was added to the end of the member list. A process already running as webdev would keep its old list; the next one started as webdev gets the new one.
useradd gave webdev no password. Its line in /etc/shadow holds ! in the password field, which no password can match, so nobody can log in to webdev with a password. On this server nobody is ever given a password, and webdev keeps none. passwd -S, status, prints the password state of an account. It reads /etc/shadow, so for any account but your own it needs root. You are in your home directory. Ask for the state of webdev without sudo first:
prompt: admin@server1:~$ answer: passwd -S webdev output: passwd: You may not view or modify password information for webdev. hint: Section 20.14. The password command with its status option -S and the name webdev, with no sudo in front.
passwd itself refused. It is setuid root (Section 20.6), so it could read the file, and it checks who asked: an ordinary account may see only its own state.
You are in your home directory. Ask again through sudo, exactly as the rule lists it. The date on your screen is the day you created the account:
prompt: admin@server1:~$ answer: sudo passwd -S webdev output: webdev L 2026-09-30 0 99999 7 -1 hint: Section 20.14. sudo, then the password command with -S and the name webdev.
Seven fields. The name, then L, locked; the other states are P, a usable password, and NP, no password at all. Then the date of the last password change, the day useradd ran. The four numbers are the ageing rules from /etc/login.defs: at least 0 days between changes, at most 99999, a warning 7 days before, and -1, never disabled after expiry.
Section 7.13 ran commands as operator with sudo -u. The policy has two rules for webdev: whoami and id, each with no arguments. sudo needs no password from webdev: the rule decides, and webdev has none to give. You are in your home directory. Ask which account the command runs as:
prompt: admin@server1:~$ answer: sudo -u webdev whoami ||| sudo --user webdev whoami ||| sudo --user=webdev whoami output: webdev hint: Section 20.15. sudo with -u and the account webdev, then the one-word identity command.
One word: the command ran as webdev, and your own shell is still admin.
You are in your home directory. Print the identity record of a command running as webdev:
prompt: admin@server1:~$ answer: sudo -u webdev id ||| sudo --user webdev id ||| sudo --user=webdev id output: uid=1002(webdev) gid=1002(webdev) groups=1002(webdev),1100(webteam) hint: Section 20.15. sudo with -u and the account webdev, then the two-letter identity command.
UID 1002, the primary group webdev, and webteam, which it gained in Section 20.13. id -Gn webdev in Exercise 20-70 read the database; this record belongs to a process that actually ran as webdev. The two agree, and a file of the group webteam with group read permission is now readable by webdev.
useradd by its full path and without sudo, /usr/sbin/useradd -m -s /bin/bash webdev, starts and refuses:
useradd: Permission denied.
useradd: cannot lock /etc/passwd; try again later.The same account twice, sudo useradd -m -s /bin/bash webdev when webdev exists:
useradd: user 'webdev' already exists-G without -a, sudo usermod -G webteam webdev, which this policy does not list:
Sorry, user admin is not allowed to execute '/usr/sbin/usermod -G webteam webdev' as root on server1.useradd locks the account files before it changes them, so that two programs never write them at once. Only root may create that lock, which is why an ordinary account gets Permission denied and then the lock message; the fix is sudo, not a second try. already exists means the account was created before: check it with getent passwd instead of creating it again. The sudo refusal has the shape of Section 7.15. Here it protects the other groups of webdev, which that line would remove.
getent reads a record from the account database, getent passwd for accounts and getent group for groups, through the lookup every program uses (Section 20.11).
useradd creates an account: its line in /etc/passwd, a locked password in /etc/shadow, a private group of the same name, and with -m a home directory copied from /etc/skel. It lives in /usr/sbin and needs root, which on this server means one exact sudo line (Section 20.12).
usermod -aG adds supplementary groups and keeps the others; -G without -a replaces the list (Section 20.13).
passwd -S prints the password state; L means locked, and an account created without a password is locked. It shows another account only to root (Section 20.14).
sudo -u runs one command as another account, as the policy allows, with that account's groups (Section 20.15).
| Key topic | What it is | Section |
|---|---|---|
| getent passwd, getent group | One record from the account or the group database | 20.11 |
| useradd -m -s /bin/bash | Create an account with a home directory and a login shell | 20.12 |
| Private group | A group with the name of one account, created with it | 20.12 |
| /usr/sbin | Administration programs, outside the PATH of an ordinary account | 20.12 |
| usermod -aG | Add supplementary groups and keep the others | 20.13 |
| passwd -S | The password state: L locked, P usable, NP none | 20.14 |
| sudo -u | Run one command as another account | 20.15 |
| Term | Definition |
|---|---|
| account database | The records of every account; on this server /etc/passwd and /etc/shadow |
| getent | The command that reads one record from a system database |
| useradd | The command that creates an account |
| adduser | A Debian program that asks questions and runs useradd |
| /etc/skel | The files copied into every new home directory |
| private group | A group named after one account, with that account as its only user |
| usermod | The command that changes an existing account |
| locked password | A password field no password can match, shown as L |
| password ageing |