Learn › Linux for Production Support › Ananya audits who has access to what

Linux for Production Support Ch 18 / 32 Intermediate

🔐

Ananya audits who has access to what

Users, groups, permissions, sudo — controlling access on production servers

⏱ 13 min 6 commands 5 takeaways

🔐

In this chapter

Ananya

Security engineer, production access audit

The story

Ananya joined the security team after 4 years as a developer. Her first week she got a task: audit who has access to what on the production servers, remove accounts of people who left the company 6 months ago, and set up a new developer with only the permissions they actually need.

On Windows she would have opened Computer Management, clicked Local Users and Groups, and done it all with right-clicks. On Linux she had a terminal and a lot of text files.

USERS AND GROUPS — THE BASICS

Every Linux process runs as a user. Every file belongs to a user and a group. Permissions are set per user, per group, and for everyone else.

Listing users:

cat /etc/passwd                # all users on the system
cat /etc/passwd | grep -v nologin | grep -v false   # only real user accounts
getent passwd vijay            # info for a specific user
id vijay                       # user ID, group ID, all groups
whoami                         # who am I right now
who                            # who is currently logged in
last                           # login history (like Windows Security event log)
lastlog                        # last login for every user

Reading /etc/passwd format:

username:x:1001:1001:Full Name:/home/username:/bin/bash
vijay:x:1001:1001:Vijay Kumar:/home/vijay:/bin/bash

# Fields: username, password(x=in shadow file), UID, GID, comment, home, shell

Listing groups:

cat /etc/group                  # all groups
groups vijay                    # what groups is vijay in?
id vijay                        # same info with more detail

CREATING AND MANAGING USERS

sudo useradd -m -s /bin/bash -c "New Developer" newuser
# -m creates home directory
# -s sets shell to bash
# -c is a comment (full name)

sudo passwd newuser             # set their password
sudo usermod -aG docker newuser # add to docker group (can now run docker)
sudo usermod -aG sudo newuser   # add to sudo group (can use sudo)

# Lock an account (departing employee - disable without deleting):
sudo usermod -L vijay           # lock — they cannot log in
sudo usermod -U vijay           # unlock

# Delete a user:
sudo userdel vijay              # delete user but keep home directory
sudo userdel -r vijay           # delete user AND home directory

# Check when passwords expire:
sudo chage -l vijay             # password aging info
sudo chage -E 2026-12-31 vijay  # set account expiry date

SUDO — WHO CAN RUN WHAT

cat /etc/sudoers                # sudo rules (never edit directly!)
sudo visudo                     # correct way to edit sudoers safely

# Check if a user can sudo:
sudo -l -U vijay                # list what vijay can run with sudo

# Common sudoers entries:
vijay ALL=(ALL:ALL) ALL         # vijay can run anything as anyone
vijay ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx   # no password for this one command
%developers ALL=(ALL) /usr/bin/docker                    # group developers can run docker

FILE PERMISSIONS IN DEPTH

ls -la /opt/app/
# drwxr-xr-x 5 tomcat appteam 4096 Mar 16 /opt/app/
# -rw-r--r-- 1 tomcat appteam  256 Mar 16 config.xml

# Permission string: drwxr-xr-x
# d = directory
# rwx = owner (tomcat): read, write, execute
# r-x = group (appteam): read, execute
# r-x = others: read, execute

Octal notation (the numbers):

chmod 644 file.txt     # rw-r--r--  (owner read/write, others read only)
chmod 755 script.sh    # rwxr-xr-x  (owner full, others read+execute)
chmod 700 private/     # rwx------  (owner only, nobody else can see inside)
chmod 640 config.xml   # rw-r-----  (owner read/write, group read, others nothing)

# Memorise: 4=read, 2=write, 1=execute. Add them up.
# 7 = 4+2+1 = rwx
# 6 = 4+2   = rw-
# 5 = 4+1   = r-x
# 4 =         r--

# Recursive: apply to directory and everything inside
chmod -R 755 /opt/app/
chown -R tomcat:appteam /opt/app/

Special permissions:

chmod +x script.sh      # add execute permission (any user)
chmod g+w file.txt      # add write permission for group
chmod o-r secret.txt    # remove read from others
chmod a+r public.txt    # add read for all (a = all)

FINDING FILES BY PERMISSION OR OWNER

find /opt -user tomcat                # all files owned by tomcat
find /opt -group appteam             # all files owned by appteam group
find /var/log -perm /o+w            # files writable by others (security risk!)
find / -perm /4000 2>/dev/null      # SUID files (run as owner — security audit)
find /home -name "*.sh" -perm /111  # executable scripts in home dirs

Ananya completed the audit in 2 hours. She found 3 old accounts from departed employees, locked them, set expiry on 4 contractor accounts, and created the new developer account with only the permissions they needed. All documented, all auditable, all reversible.

Key takeaways

cat /etc/passwd shows all users — filter with grep -v nologin to see only real accounts

sudo usermod -L username locks an account without deleting it — use for departing employees

chmod uses octal: 7=rwx, 6=rw-, 5=r-x, 4=r-- — add them up (4=read, 2=write, 1=execute)

chown -R user:group directory changes ownership recursively — always check before running on /

find / -perm /4000 finds SUID files — part of any security audit

Commands from this chapter

$ id username

Show user ID, group ID, and all groups for a user

$ sudo useradd -m -s /bin/bash username

Create a new user with home directory and bash shell

$ sudo usermod -aG docker username

Add user to a group without removing existing groups

$ sudo usermod -L username

Lock account — user cannot log in (departing employee)

$ chmod 755 script.sh

Set permissions: owner full, group and others read+execute

$ find /opt -user tomcat -not -perm 644

Find files owned by tomcat that are not 644