Day 5 - Users, Groups, and Sudo

Accounts and privileges form the base of system security. This lesson explains user and group records, how to create and modify accounts, how to grant controlled administrative rights with sudo, and how to keep account data safe.

Prerequisites

• Day 1 through Day 4 completed
• A terminal and a user account with sudo

Inspect current identity and records

1
2
3
4

whoami                    # current username
id                        # uid, gid, and group memberships
getent passwd "$USER"     # full user record
getent group sudo 2>/dev/null || getent group wheel

Record formats:

• /etc/passwd fields: name:x:uid:gid:gecos:home:shell
• /etc/group fields: name:x:gid:members
• /etc/shadow fields are readable only by root and hold password hashes and aging data

Create users and groups

Debian and Ubuntu provide adduser with friendly prompts. Low level tools are useradd, groupadd, and passwd on all distributions.

1
2
3
4
5
6
7
8
9
10
11
12

# create a group
sudo groupadd developers || true

# create a user with a home directory and default shell
sudo useradd -m -s /bin/bash alice
sudo passwd alice

# add existing user to a group
sudo usermod -aG developers alice

# Fedora family often uses wheel group for sudo
getent group wheel || sudo groupadd wheel || true

Check results.

1
2
3

getent passwd alice
id alice
getent group developers

Remove accounts safely.

1
2

sudo userdel -r alice    # remove user and home directory
sudo groupdel developers || true

Passwords, locking, and aging

1
2
3
4
5
6
7
8
9
10

# set or change a password
sudo passwd bob

# lock or unlock an account without changing the password hash
sudo passwd -l bob
sudo passwd -u bob

# view and set password aging
sudo chage -l bob
sudo chage -M 90 -W 14 bob   # max age 90 days, warn 14 days before expiry

For public key only users on servers, consider locking the password and requiring SSH keys.

sudo basics and least privilege

Sudo lets trusted users run specific commands as root or as another user. Always grant the minimum required access.

Check sudo version and policy path.

1

sudo -V | grep -E "Sudoers|visudo|Plugins" -n

Grant access by adding users to a sudo group that is already enabled by the distribution.

1
2
3
4
5
6
7

# Ubuntu and Debian family
grep -nE "%sudo|%admin" /etc/sudoers
sudo usermod -aG sudo "$USER"    # or admin on older releases

# Fedora and many RHEL based systems
grep -n "%wheel" /etc/sudoers
sudo usermod -aG wheel "$USER"

Test sudo and record a log entry.

1
2

sudo -l           # list allowed commands
sudo whoami       # should print root if policy allows

Example minimal policy in a drop in file.

1
2
3

# create a drop in
printf '%s\n' '%sudo ALL=(ALL:ALL) ALL' | sudo tee /etc/sudoers.d/00-sudo-group >/dev/null
sudo visudo -c   # validate

Limit access to one command with a command alias.

1
2
3
4
5

# allow the deploy group to restart a service only
printf '%s\n' \
'Cmnd_Alias RESTART = /usr/bin/systemctl restart myapp.service' \
'%deploy ALL=(root) NOPASSWD: RESTART' | sudo tee /etc/sudoers.d/deploy-restart >/dev/null
sudo visudo -c

Use sudoedit for safe file edits with elevated rights.

1

sudoedit /etc/ssh/sshd_config

Audit sudo use.

1

sudo journalctl -t sudo -r 2>/dev/null || sudo grep -i sudo /var/log/auth.log 2>/dev/null

su versus sudo

• su starts a shell as another user and requires that user's password. su - simulates a full login shell.
• sudo runs a single command as root or another user and authenticates the invoking user. It supports detailed policy and logging.

Prefer sudo for admin tasks on most systems. Use su - only when a full root shell is necessary and allowed by policy.

Fixing ownership and group access

1
2
3
4
5
6
7

# take ownership of a home subdirectory
sudo chown -R "$USER":"$USER" "$HOME/projects"

# set a shared directory with team write access
sudo mkdir -p /srv/shared
sudo chgrp developers /srv/shared
sudo chmod 2775 /srv/shared     # setgid so new files inherit the group

Practical lab

Create a limited operator role for restarting one service and confirm logging and prompts.

1. Create a deploy group and add a test user.

1
2
3
4

sudo groupadd deploy || true
sudo useradd -m -s /bin/bash operator || true
sudo usermod -aG deploy operator
sudo passwd operator

2. Add a narrow sudo policy.

1
2
3

sudo bash -c 'cat > /etc/sudoers.d/deploy-restart <<"EOF"\nCmnd_Alias RESTART = /usr/bin/systemctl restart nginx.service\n%deploy ALL=(root) NOPASSWD: RESTART\nEOF'

sudo visudo -c

3. Verify.

1

sudo -u operator -H bash -lc 'id; sudo -l; sudo systemctl restart nginx.service; sudo -l'

4. Check logs.

1

sudo journalctl -t sudo -r 2>/dev/null || sudo tail -n 50 /var/log/auth.log 2>/dev/null

Troubleshooting

• user is not in the sudoers file Add the user to the correct group or create a drop in under /etc/sudoers.d/. Validate with visudo -c.
• Group membership changes do not apply in the current shell. Log out and in again or run newgrp <group>.
• permission denied on a shared directory. Ensure the group owns the directory and that the setgid bit is set. Example chmod 2775 /srv/shared.
• Sudo prompt does not accept the password. Confirm the keyboard layout and that Caps Lock is off. Check account lock status with passwd -S <user> and unlock if needed.
• Remote accounts from LDAP or AD are missing. Confirm that getent returns them and that sssd or the name service is running.

Next steps

Day 6 covers permissions and ownership in depth. It explains the rwx model, directory execution rules, special bits like setgid and sticky, default permissions with umask, and introduces ACLs for fine grained control.