Overview

You manage Linux user accounts, groups, sudo privileges, and access controls. This skill provides practical, step-by-step guidance for creating and modifying users and groups, configuring secure sudo access, applying ACLs for fine-grained permissions, and handling SUID/SGID/Sticky bits on files and directories.

How This Skill Works

You operate on core Linux primitives for identity and access: users (/etc/passwd, /etc/shadow), groups (/etc/group), and permissions. You create and modify accounts with useradd/usermod/userdel, manage groups with groupadd/groupmod/groupdel, and assign users to groups. For elevated privileges, you configure sudoers via visudo or /etc/sudoers.d to grant least-privilege access. For granular file permissions, you read and set ACLs with getfacl/setfacl in addition to traditional UNIX permissions, and you can enforce special behaviors with SUID/SGID/Sticky bits using chmod. Verification is done with commands like id, groups, getfacl, ls -la, and by inspecting /etc/sudoers.d entries.

When to Use It

• When onboarding a new developer and granting controlled sudo capabilities (Scenario 1).
• When you need a shared project directory that automatically inherits the group (SGID) and proper permissions (Scenario 2).
• When you must restrict a user to specific commands via sudoers instead of giving full root access (Scenario 3).
• When you require fine-grained access to individual files without changing ownership using ACLs (e.g., granting a read/write to a file for a specific user or group).
• When auditing permissions and ensuring password policies, account locks, and default behaviors are consistently applied across the system.

Quick Start

1. Create a new user and assign to a group:
2. - groupadd developers
3. - useradd -m -s /bin/bash -G developers devuser
4. Set a password for the new user:
5. passwd devuser
6. Configure sudo privileges for the user via a dedicated sudoers file (recommended):
7. echo "devuser ALL=(ALL) NOPASSWD: /usr/bin/docker, /usr/bin/systemctl" > /etc/sudoers.d/devuser
8. chmod 440 /etc/sudoers.d/devuser
9. Optionally prepare a shared directory with SGID so new files inherit the group:
10. mkdir /shared
11. groupadd shared
12. chown root:shared /shared
13. chmod 2775 /shared

Best Practices

• Prefer group-based permissions and assign users to roles via groups rather than granting access to individual users.
• Use the /etc/sudoers.d method for sudo privileges; avoid editing /etc/sudoers directly unless necessary to reduce conflicts during upgrades.
• Limit sudo privileges to only the exact commands needed; avoid broad NOPASSWD where possible unless you have a controlled, auditable environment.
• Use ACLs to grant fine-grained access in addition to standard UNIX permissions, and verify with getfacl after changes.
• Apply SGID on shared directories to ensure new files inherit the correct group ownership, and document group ownership conventions for consistency.
• Regularly audit sudoers entries, user memberships, and ACLs; disable or lock unused accounts with usermod -L and monitor for password policy compliance with chage.
• When removing access, clean up associated ACLs, sudoers entries, and group memberships to prevent orphaned rights.

Example Use Cases

• Onboarding a new developer: create a dev user, add to the developers group, set a password, and grant narrowly scoped sudo rights via /etc/sudoers.d to manage Docker and systemctl usage.
• Shared project workspace: establish a /shared directory owned by root:shared with 2775 permissions; add developers to the shared group so new files inherit the group.
• Restrict a user to specific commands: configure a sudoers entry that only allows running systemctl status and journalctl for a given user, reducing blast radius while maintaining needed visibility.
• Fine-grained access with ACLs: grant read access to a confidential log file for a junior engineer without changing file ownership, using getfacl/setfacl to apply u:engineering:rx or r-x as needed.
• Special permissions management: enable a SUID binary where execution should run with the file owner’s privileges, or apply STICKY on /tmp to restrict deletions to file owners.

Frequently Asked Questions