Learn › Linux Foundations › Permissions, Ownership and Users
Part 2 of 3: id and the groups of an account, the permission check, chgrp, chown through the exact sudo rules of the server, and owner:group (Sections 20.7 to 20.10). No machine test here; it completes on the final step. The chapter lab waits at the end of Part 3.
This chapter covers the following topics:
This is Part 2 of 3. Part 1 covered Sections 20.1 to 20.6, the mode and how to change it. This part covers Sections 20.7 to 20.10: the groups of your account, how the system picks the class that applies to you, and the group and the owner of a file. Part 3 covers Sections 20.11 to 20.15, accounts, and ends in the chapter lab, which covers all fifteen sections.
What you already know: Part 1 read and changed the mode of a file. Section 7.2 read your identity record with id, Section 7.10 ran a command as root with sudo, and Section 7.11 printed the sudo policy of this server with sudo -l.
Objectives
After this part you can:
Select Start machine in the adjacent workspace and use its Terminal. The guided ownership changes affect real prepared files for this session. This part has no separate graded lab; it completes on its final step. The chapter assessment starts a fresh machine after Part 3 and checks file, account and group state and the commands you run.
Five questions before the material. A wrong answer costs nothing: the explanation states the fact and names the section that teaches it.
>>> The check goes owner, then group, then others, and the first class that matches decides. admin is not the owner and is in the group, so the group bits apply. Section 20.7.
>>> The owner may move a file to any group the owner belongs to. Any other group, or a file owned by someone else, needs root. Section 20.8.
>>> Changing the owner is reserved for root, even for the owner of the file, so that no account can put files under another account's name. Section 20.9.
>>> A sudo rule allows a command line, not a program: the program, every argument and the account it runs as are fixed. sudo -l lists them. Section 20.9, and Section 7.11 before it.
>>> In owner:group the part before the colon is the new owner and the part after it the new group; chown sets both at once. Section 20.10.
Section 7.2 read your identity record with id. Its gid is your primary group, the group every new file you create belongs to. The list after groups= adds your supplementary groups, every other group you are a member of, as Section 7.4 showed for operator. This server has a group named webteam, with the number (GID) 1100, for the accounts that maintain the website, and admin is a member. You are in your home directory. Print your record:
prompt: admin@server1:~$ answer: id output: uid=1000(admin) gid=1000(admin) groups=1000(admin),1100(webteam) hint: Section 7.2. The two-letter identity command on its own, with no argument.
UID 1000 is admin, and the primary group is admin, GID 1000. The list of groups holds two: admin again, and webteam, GID 1100. Every command you start carries this identity, and the permission check of every file compares it with the owner and the group of that file.
Section 7.3 printed single parts of the record. -G prints every group and -n prints names instead of numbers. The command groups prints the same list. You are in your home directory. Print the names of your groups:
prompt: admin@server1:~$ answer: id -Gn ||| id -nG ||| id -G -n ||| groups output: admin webteam hint: Section 20.7. The identity command with -G for every group and -n for names, written together as -Gn.
The primary group first, then the supplementary groups. A group added while you are logged in reaches your shell only at the next login: the list is copied into a process when it starts.
A process is a running program (Section 4.10); your shell is one, and every command it starts is another. When a process asks to read, write or run a file, the system compares the account and the groups of the process with the owner and the group of the file, and checks exactly one class:
{ "caption": "Is the process running as the owner of the file? If not, is it in the group of the file? The first question answered yes picks the class, and the bits of that class decide. There is no second try with another class.", "nodes": [ { "id": "p", "label": "a process asks", "kind": "command", "col": 0, "row": 0 }, { "id": "o", "label": "the owner?", "kind": "command", "col": 1, "row": 0 }, { "id": "g", "label": "in the group?", "kind": "command", "col": 2, "row": 0 }, { "id": "x", "label": "others bits", "kind": "file", "col": 3, "row": 0 }, { "id": "ob", "label": "owner bits", "kind": "file", "col": 1, "row": 1 }, { "id": "gb", "label": "group bits", "kind": "file", "col": 2, "row": 1 } ], "edges": [ { "from": "p", "to": "o", "kind": "plain", "stage": 1 }, { "from": "o", "to": "ob", "label": "yes", "kind": "stdout", "stage": 2 }, { "from": "o", "to": "g", "label": "no", "kind": "plain", "stage": 2 }, { "from": "g", "to": "gb", "label": "yes", "kind": "stdout", "stage": 3 }, { "from": "g", "to": "x", "label": "no", "kind": "plain", "stage": 3 } ] }
root is the one exception: the check does not stop it, which is why Section 7.12 could read a root-only file through sudo. You are in your home directory. The directory access/groups holds two files for this part. List it in long form:
prompt: admin@server1:~$ answer: ls -l access/groups ||| ls -l access/groups/ ||| ls -l ~/access/groups output: total 8 -rw-r--r-- 1 admin admin 84 Jan 15 2026 handover.txt -rw-r----- 1 root webteam 85 Jan 15 2026 roster.txt hint: Section 2.4. The long listing -l, then the path access/groups (or ~/access/groups from anywhere).
The third and fourth columns are the owner and the group. handover.txt belongs to admin and to the group admin. roster.txt belongs to root and to the group webteam, with the mode 640: the owner may read and write, the group may read, others nothing.
You are not the owner of roster.txt; root is. You are in its group, webteam. You are in your home directory. Print access/groups/roster.txt:
prompt: admin@server1:~$ answer: cat access/groups/roster.txt ||| cat ~/access/groups/roster.txt output: webteam: the accounts that maintain the website admin pages, releases and backups hint: Section 5.1. The printing command, then the path access/groups/roster.txt (or ~/access/groups/roster.txt from anywhere).
The file opened through the group class: owner? no; in the group webteam? yes; so the group bits r-- decide, and they allow reading. This is how a group shares files: every member reads them without being their owner.
Section 7.14 needed sudo to read /var/log/auth.log. You are in your home directory. Print its mode, owner and group with the stat format of Section 20.1:
prompt: admin@server1:~$ answer: stat -c '%A %a %U %G %n' /var/log/auth.log ||| stat -c "%A %a %U %G %n" /var/log/auth.log ||| stat --format='%A %a %U %G %n' /var/log/auth.log output: -rw-r----- 640 root adm /var/log/auth.log hint: Section 20.1. The stat format '%A %a %U %G %n', then the absolute path /var/log/auth.log.
The same mode as roster.txt, 640, and the same owner, root. The group differs: adm, the group Debian gives read access to its logs, and admin is not a member. So for this file admin falls in the others class, ---, and cat was refused. The mode alone never answers who may read a file; the mode and the groups do.
chgrp, change group, sets the group of a file. The owner of a file may change it to any group the owner is a member of; root may use any group. The mode stays as it is, so the new group gets the group bits the file already has. You are in your home directory. Change the group of access/groups/handover.txt to webteam:
prompt: admin@server1:~$ answer: chgrp webteam access/groups/handover.txt ||| chgrp webteam ~/access/groups/handover.txt output: hint: Section 20.8. The change-group command, the group webteam, then the path access/groups/handover.txt (or ~/access/groups/handover.txt from anywhere).
Silent, like chmod. The members of webteam now read the file through the group bits r--.
You are in your home directory. List access/groups/handover.txt in long form:
prompt: admin@server1:~$ answer: ls -l access/groups/handover.txt ||| ls -l ~/access/groups/handover.txt output: -rw-r--r-- 1 admin webteam 84 Jan 15 2026 access/groups/handover.txt hint: Section 2.4. The long listing -l, then the path access/groups/handover.txt (or ~/access/groups/handover.txt from anywhere).
The group column reads webteam. On this file, the owner and mode remain the same. The displayed Jan 15 date is the content modification time, which chgrp did not change. A group change does update the file's metadata change time, and on some files it can clear special permission bits.
Section 7.4 met the group operator, and admin is not a member of it. You are in your home directory. Try to change the group of access/groups/handover.txt to operator:
prompt: admin@server1:~$ answer: chgrp operator access/groups/handover.txt ||| chgrp operator ~/access/groups/handover.txt output: chgrp: changing group of 'access/groups/handover.txt': Operation not permitted hint: Section 20.8. The change-group command, the group operator, then the path access/groups/handover.txt (or ~/access/groups/handover.txt from anywhere).
Operation not permitted, the refusal of Section 20.3 for an action reserved to someone else. You own the file, but you may only choose a group you belong to. Otherwise any account could hand its files to a group whose members never asked for them.
chown, change owner, can set a file's owner, its group, or both. Changing a file to a different owner requires root, even when the file is yours. As an ordinary owner, you may change its group to one you belong to; Section 20.8 used chgrp for that. You cannot give the file to another account without an allowed sudo rule. You are in your home directory. Try to give access/groups/handover.txt to the account operator:
prompt: admin@server1:~$ answer: chown operator access/groups/handover.txt ||| chown operator ~/access/groups/handover.txt output: chown: changing ownership of 'access/groups/handover.txt': Operation not permitted hint: Section 20.9. The change-owner command, the account operator, then the path access/groups/handover.txt (or ~/access/groups/handover.txt from anywhere).
Refused, with the same wording as chgrp. Changing an owner is reserved for root, so this is a job for sudo, and sudo runs only what a rule allows.
Section 7.11 read the sudo policy of this server with sudo -l: every rule names one program by its full path with its arguments fixed, and no password is asked. This chapter adds nine rules to it. You are in your home directory. Print the policy:
prompt: admin@server1:~$ answer: sudo -l ||| sudo --list output: Matching Defaults entries for admin on server1: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty, !authenticate
User admin may run the following commands on server1: ... (root) NOPASSWD: /usr/bin/chown operator /srv/handoff/changelog.txt (root) NOPASSWD: /usr/bin/chown admin\:webteam /srv/handoff/changelog.txt (root) NOPASSWD: /usr/bin/chown operator /srv/handoff/backup-plan.txt (root) NOPASSWD: /usr/bin/chown admin\:webteam /srv/handoff/team-roster.txt (root) NOPASSWD: /usr/sbin/useradd -m -s /bin/bash webdev (root) NOPASSWD: /usr/sbin/usermod -aG webteam webdev (root) NOPASSWD: /usr/bin/passwd -S webdev (webdev) NOPASSWD: /usr/bin/whoami "" (webdev) NOPASSWD: /usr/bin/id "" ... hint: Section 7.11. The borrowing word sudo with the option that lists your rules, -l. It takes no path.
The lines shown as ... are the rules other chapters use, Chapter 7's before these and Chapter 15's after them; your screen prints them in full. The nine lines between them are this chapter's.
Four are chown rules, and each fixes the new owner and one file: operator for changelog.txt and for backup-plan.txt, admin:webteam for changelog.txt and for team-roster.txt. In the file that holds the rules, a colon inside an argument must be written with a backslash in front, and sudo -l prints it that way, admin\:webteam. You type a plain colon.
Part 3 uses the other five: useradd, usermod and passwd -S for one account, webdev, and whoami and id run as that account. None of the nine lets admin run a shell or editor as root. The chown rules each name one target in /srv/handoff; the other rules fix the webdev account and the permitted identity commands. These limits keep the grant narrow.
Every chown rule names a file in /srv/handoff. /srv holds the data a server provides, and handoff is where this server keeps files that pass from one account to another. You are in your home directory. List the directory /srv/handoff itself:
prompt: admin@server1:~$ answer: ls -ld /srv/handoff ||| ls -dl /srv/handoff ||| ls -ld /srv/handoff/ output: drwxr-xr-x 2 root root 4096 Jan 15 2026 /srv/handoff hint: Section 20.4. The listing command with -l and -d together, then the absolute path /srv/handoff.
Owned by root, mode 755: admin may list the directory and pass through it, but cannot add, remove or rename an entry there (Section 20.4). That prevents this ordinary account from replacing a named entry in the directory. It is one safeguard for this prepared sudo rule, not a complete safety proof: the exact command and arguments, the target file and any link handling also matter. Inspect the active rule with sudo -l before relying on it.
You are in your home directory. List /srv/handoff in long form:
prompt: admin@server1:~$ answer: ls -l /srv/handoff ||| ls -l /srv/handoff/ output: total 12 -rw-r--r-- 1 admin admin 53 Jan 15 2026 backup-plan.txt -rw-r--r-- 1 admin admin 65 Jan 15 2026 changelog.txt -rw-r--r-- 1 admin admin 54 Jan 15 2026 team-roster.txt hint: Section 2.4. The long listing -l, then the absolute path /srv/handoff.
Three files owned by admin and the group admin, mode 644, in a directory owned by root. This part works on changelog.txt; the other two belong to the chapter lab.
The first rule gives changelog.txt to operator. The path must be written exactly as the rule lists it, from the root. You are in your home directory. Give /srv/handoff/changelog.txt to operator:
prompt: admin@server1:~$ answer: sudo chown operator /srv/handoff/changelog.txt output: hint: Section 20.9. The borrowing word sudo, the change-owner command, the account operator, then the absolute path /srv/handoff/changelog.txt exactly as sudo -l lists it.
Silent. sudo ran chown as root because the command line matched a rule word for word, and no password was asked.
You are in your home directory. List /srv/handoff/changelog.txt in long form:
prompt: admin@server1:~$ answer: ls -l /srv/handoff/changelog.txt output: -rw-r--r-- 1 operator admin 65 Jan 15 2026 /srv/handoff/changelog.txt hint: Section 2.4. The long listing -l, then the absolute path /srv/handoff/changelog.txt.
The owner is operator. The group is still admin, because a chown that names only an owner leaves the group alone. The mode and the date did not change either. chown also clears the setuid and setgid bits of a program it gives away, so a program can never become setuid to its new owner this way.
You are in the group of the file, admin, and no longer its owner. You are in your home directory. Update the time of /srv/handoff/changelog.txt with touch:
prompt: admin@server1:~$ answer: touch /srv/handoff/changelog.txt output: touch: cannot touch '/srv/handoff/changelog.txt': Permission denied hint: Section 6.1. The c
Practice Chapter 20, Part 2. Permissions, Ownership and Users: id, chgrp, chown and sudo -l in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.