Users and groups: who can do what
Create, change, lock and remove accounts, use groups to share access, give exactly the sudo rights someone needs, and run services as accounts nobody can log in to.
By the end of this lesson you'll be able to
0 of 6 completeWho you are
Every process runs as a user, and every file belongs to a user and a group. Linux decides what's allowed by comparing the two. Start by looking at yourself:
$ id uid=1000(rajeev) gid=1000(rajeev) groups=1000(rajeev),4(adm),27(sudo),998(docker) $ getent passwd rajeev rajeev:x:1000:1000:Rajeev Kumar:/home/rajeev:/bin/bash
Your primary group (gid) is given to the files you create. Your supplementary groups give
extra access: sudo lets you use sudo, docker lets you talk to Docker, adm lets you read
many logs.
Where accounts live
| File | Holds | Readable by |
|---|---|---|
/etc/passwd | names, ids, home folders, shells | everyone |
/etc/shadow | password hashes, password ageing | root only |
/etc/group | groups and their members | everyone |
$ getent group devops # a group and its members devops:x:1005:asha,ravi $ awk -F: '$3 >= 1000 {print $1}' /etc/passwd # human accounts (ids from 1000)
User ids below 1000 belong to the system and to services (www-data, postgres, sshd). Don't
edit these files by hand: the tools below lock them, validate the fields and keep the three files
in step. getent also asks LDAP or other directories if the server uses them.
Creating, changing and removing users
$ sudo useradd -m -s /bin/bash -c "Asha Verma" asha # -m home folder, -s shell, -c full name $ sudo passwd asha # set her first password $ sudo chage -d 0 asha # must choose a new one at first login $ sudo chage -l asha # password ageing details $ sudo usermod -s /bin/zsh asha # change her shell $ sudo usermod -L asha # lock: no password logins $ sudo usermod -U asha # unlock $ sudo chage -E 2026-12-31 contractor1 # the account expires on that date $ sudo userdel -r olduser # delete the user and their home folder
sudo useradd -m -s /bin/bash -c "Asha Verma" ashasudorun the next command as root
New home folders are copied from /etc/skel. Put a default .bashrc there and every new user
gets it.
On Debian and Ubuntu, adduser asha is a friendlier wrapper that asks questions and creates the
home folder for you. Scripts and other distributions use useradd, so learn that one.
Groups
$ sudo groupadd devops # create a group $ sudo usermod -aG devops asha # ADD asha to devops (keeps her other groups) $ id asha uid=1001(asha) gid=1001(asha) groups=1001(asha),1005(devops) $ sudo gpasswd -d asha devops # remove her from one group $ sudo groupmod -n platform devops # rename the group $ sudo groupdel platform # delete it
sudo groupadd devopssudorun the next command as root
Group changes apply at the next login. The person has to log out and back in (or run
newgrp devops) before id shows the new group in their session.
Service accounts
Programs should run as their own user, never as root and never as a person:
$ sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp $ sudo chown -R myapp:myapp /srv/myapp $ sudo -u myapp /srv/myapp/bin/server # run something AS that user
sudo useradd --system --no-create-home --shell /usr/sbin/nologin myappsudorun the next command as root
sudo chown -R myapp:myapp /srv/myappchownchange owner
If the app is broken into, the attacker gets only what myapp can touch, and nologin means
nobody can open a shell as it. Package installs already do this: www-data for nginx, postgres
for PostgreSQL.
sudo rights: exactly what is needed
Members of the sudo group (wheel on Red Hat systems) may run anything as root. That's right for
administrators and too much for most people. Give everyone else exactly the commands they need,
in a separate file per team:
$ sudo visudo -f /etc/sudoers.d/devops
sudo visudo -f /etc/sudoers.d/devopssudorun the next command as root
# devops may manage nginx, nothing else %devops ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx
$ sudo visudo -c # check every sudoers file /etc/sudoers: parsed OK /etc/sudoers.d/devops: parsed OK $ sudo -l -U asha # what may asha run? User asha may run the following commands on web-01: (root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx
sudo visudo -csudorun the next command as root
Always use full paths in rules (which systemctl tells you), and always edit with visudo: it
refuses to save a file with a mistake in it. Be careful with NOPASSWD: and with programs that
can start a shell (editors, less, find -exec, any script the user can edit): allowing them is
the same as allowing everything.
su - asha switches to another account and needs her password. sudo -iu asha does the same
with your sudo rights, which is how admins check a user's environment without knowing their
password.
A shared team folder
Combine groups with the setgid bit from the previous lessons:
$ sudo mkdir -p /srv/app $ sudo chgrp devops /srv/app $ sudo chmod 2775 /srv/app # 2 = setgid, 775 = rwx for owner and group $ ls -ld /srv/app drwxrwsr-x 2 root devops 4096 Oct 13 12:10 /srv/app
sudo mkdir -p /srv/appsudorun the next command as rootmkdirmake a directory-pcreate missing parents, no error if it exists
sudo chmod 2775 /srv/appchmodchange permissions
ls -ld /srv/applslist files
The s in the group set is setgid: everything created inside belongs to devops, whoever
creates it, so the whole team can edit everything.
Onboard a developer and a service
Asha joins the devops team. She needs a login, membership of devops, permission to restart and reload nginx with sudo (nothing else), and write access to /srv/app. The app itself must run as its own account that can't log in.
Users asha and myapp, /etc/sudoers.d/devops, /srv/appReveal one safe solution
$ sudo groupadd devops $ sudo useradd -m -s /bin/bash -c "Asha Verma" -G devops asha $ sudo passwd asha && sudo chage -d 0 asha $ echo '%devops ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx' \ | sudo EDITOR='tee' visudo -f /etc/sudoers.d/devops > /dev/null $ sudo visudo -c $ sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp $ sudo mkdir -p /srv/app && sudo chgrp devops /srv/app && sudo chmod 2775 /srv/app $ id asha uid=1001(asha) gid=1001(asha) groups=1001(asha),1005(devops) $ sudo -l -U asha | tail -n 1 (root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx $ getent passwd myapp myapp:x:998:998::/home/myapp:/usr/sbin/nologin
sudo groupadd devopssudorun the next command as root
sudo passwd asha && sudo chage -d 0 asha&&run the next command only if this one worked
echo '%devops ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx' \echoprint text
sudo mkdir -p /srv/app && sudo chgrp devops /srv/app && sudo chmod 2775 /srv/appmkdirmake a directory-pcreate missing parents, no error if it existschmodchange permissions
sudo -l -U asha | tail -n 1|pipe: send output to the next commandtailshow the last lines-nhow many lines
EDITOR='tee' visudo -f … writes the rule through visudo, so it's still syntax-checked, without
opening an editor: handy in scripts. getent shows myapp with nologin, and its user id below
1000 marks it as a system account.
Try it yourself
0 of 6 steps doneRun each task in your own account or terminal, then tick it off.
Quick check
You run sudo usermod -G docker asha. What happens to her other groups, like sudo and devops?
Official reading for this lesson
Or get every quiz answer right and it completes itself.