How to Manage Multiple Users with Sudo Permissions

Short introduction

Managing sudo permissions for multiple users is a common administrative task that keeps systems secure while allowing users to perform necessary privileged actions. This guide walks you through the basics of groups, safe editing of sudo rules, and granular privileges so you can manage multiple sudo users confidently.

Understanding sudo, users, and groups

Before assigning sudo capabilities, understand how sudo integrates with users and groups. On many distributions a special group (commonly sudo or wheel) is configured in /etc/sudoers to grant members sudo rights. Checking group membership and the sudoers configuration is the first step.

Example commands to inspect current state:

# Check your user info and groups
id $(whoami)
groups $(whoami)

# See sudoers file (read-only)
sudo cat /etc/sudoers | sed -n '1,120p'

# Find lines enabling a group (sudo, wheel, admin)
grep -E '(^%sudo|^%wheel|^%admin)' /etc/sudoers || true

Explanation:

• id and groups show which groups a user belongs to. If a user is in the sudo/wheel group and that group appears in sudoers, the user will have sudo.
• Direct edits to /etc/sudoers are dangerous; always use visudo (covered later).
• Knowing the default group on your distribution avoids accidentally granting more access than intended.

Adding and managing multiple sudo users

For multiple users, prefer group-based management. Add users to a sudo-enabled group rather than editing sudoers for every user.

Common workflow to create and add users:

# Create a new user and set a password
sudo adduser alice
# On some distros:
# sudo useradd -m -s /bin/bash alice && sudo passwd alice

# Add an existing user to the 'sudo' group
sudo usermod -aG sudo alice

# Verify membership
getent group sudo
# or
groups alice

Commands table (quick reference)

Notes:

• Use usermod -aG (append) to avoid removing a user from other groups.
• On systems using wheel instead of sudo, replace sudo with wheel in commands and sudoers entries.
• After adding user to a group, the user may need to log out and back in for the new group membership to be effective.

Granting and restricting sudo privileges safely

Granting full sudo to many users is easy but risky. Use visudo to edit /etc/sudoers safely and prefer targeted rules (allow specific commands) rather than full root access.

Open sudoers safely:

# Always use visudo (locks file and checks syntax)
sudo visudo

# To edit a drop-in file instead (preferred)
sudo visudo -f /etc/sudoers.d/50-sysadmins

Examples of sudoers lines and explanations:

# Grant full sudo to group 'sudo'
%sudo   ALL=(ALL:ALL) ALL

# Allow members of 'sysops' group to restart Apache without a password
%sysops ALL=(root) NOPASSWD: /usr/bin/systemctl restart apache2

# Allow a specific user to run a fixed command as another user
alice ALL=(postgres) /usr/bin/pg_dump

Best practices:

• Use NOPASSWD only where automation requires it; prefer prompting for password for accountability.
• Prefer command lists and Cmnd_Alias for maintainability (next section).
• Never edit /etc/sudoers directly with a text editor; a syntax error can lock out sudo.

Using Cmnd_Alias, sudoers.d and fine-grained rules

For many users with different responsibilities, sudoers supports aliases and drop-in files. This lets you centralize rules and keep them readable.

Create aliases and drop-in files:

# Create a file for a team in sudoers.d using visudo
sudo visudo -f /etc/sudoers.d/devops

# Example contents to paste via visudo:
Cmnd_Alias APACHE = /usr/bin/systemctl restart apache2, /usr/bin/systemctl status apache2
Cmnd_Alias DB = /usr/bin/systemctl restart postgresql, /usr/bin/pg_dump

%devops ALL=(root) NOPASSWD: APACHE, DB
%junior_dev ALL=(root) /usr/bin/systemctl status apache2

Make sure permissions are correct:

# Files under /etc/sudoers.d must be 0440
sudo chmod 0440 /etc/sudoers.d/devops
sudo ls -l /etc/sudoers.d/

Explanation:

• Cmnd_Alias groups commands into readable names.
• sudoers.d lets you maintain multiple small files (e.g., per team), which is easier to audit and minimize risk.
• Use Runas_Alias if users should be allowed to run commands as a non-root user (e.g., database backups as postgres).
• Use visudo -f when creating or editing drop-in files to ensure syntax checks.

Common Pitfalls

Mistyping group or command paths: The sudoers parser is strict — wrong paths or typos will either do nothing or deny expected permissions. Always use full absolute paths and test with sudo -l.

# Test effective sudo rights for a user
sudo -l -U alice

Using NOPASSWD too liberally: Removing password prompts increases automation convenience but reduces accountability and raises security risk. Restrict NOPASSWD to specific safe commands only.

# Risky: grants passwordless root to group
%devops ALL=(ALL) NOPASSWD: ALL

Forgetting to use visudo: Editing /etc/sudoers directly can corrupt the file and break sudo. Always use visudo or visudo -f /etc/sudoers.d/filename.

# Wrong: direct edit may leave syntax errors
sudo nano /etc/sudoers   # risky

Next Steps

• Implement least privilege: Replace ALL grants with specific Cmnd_Alias entries and move team rules into /etc/sudoers.d/ files to simplify reviews.
• Automate user and group management: Use configuration management (Ansible, Puppet) to add users and deploy sudoers.d snippets, so changes are reproducible and auditable.

Audit current sudo usage: Run sudo -l for representative users and examine /var/log/auth.log (or systemd journal) for sudo activity.

sudo -l -U alice
sudo journalctl _COMM=sudo --since "2 days ago"

Closing note: Start small, test each change, and prefer group-based, least-privilege rules. Properly using visudo, sudoers.d, and aliases keeps multiple-user sudo management scalable and safe.

👉 Explore more IT books and guides at dargslan.com.