# How to Restrict Sudo Privileges to Specific User Groups in Linux: A Complete Guide > Learn to restrict sudo privileges to specific user groups in Linux. Secure your server by granting access only to authorized users with our complete guide. - Repository: [IMTheNachoMan/How-To-Secure-A-Linux-Server](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server) - Tags: how-to-guide - Published: 2026-05-14 --- **You restrict sudo privileges to specific user groups by creating a dedicated UNIX group, adding authorized users to it, and configuring `/etc/sudoers` with a rule like `%sudousers ALL=(ALL:ALL) ALL` using `visudo`, which grants sudo access exclusively to group members.** In the `imthenachoman/How-To-Secure-A-Linux-Server` repository, restricting root access to a dedicated group is highlighted as a fundamental hardening practice. This method allows you to manage sudo privileges centrally without editing individual user accounts or the sudoers file for every permission change. ## Why Use a Dedicated Group for Sudo Access Managing sudo privileges through individual user entries in `/etc/sudoers` becomes unwieldy as your system scales. By creating a dedicated group such as `sudousers`, you **decouple privilege management from individual usernames**, making it trivial to grant or revoke access by simply adding or removing users from the group. This approach aligns with the "Limit Who Can Use sudo" section of the How-To-Secure-A-Linux-Server guide, reducing configuration errors and simplifying security audits. ## Step-by-Step Implementation ### 1. Create the Sudo Group First, create a dedicated UNIX group that will contain all sudo-privileged accounts. The example in the source guide uses `sudousers`, though any valid group name works. ```bash sudo groupadd sudousers ``` ### 2. Add Users to the Group Append existing user accounts to the new group using `usermod` with the `-a` (append) and `-G` (group) flags. Repeat this for every user requiring elevated privileges. ```bash sudo usermod -a -G sudousers alice sudo usermod -a -G sudousers bob ``` ### 3. Backup the Sudoers File Before modifying system-critical configuration, create a timestamped backup of `/etc/sudoers` to ensure recovery from syntax errors. ```bash sudo cp --archive /etc/sudoers /etc/sudoers.backup ``` ### 4. Configure the Sudoers Rule Edit the sudoers file safely using `visudo`, which validates syntax before saving. Add a rule that grants full sudo access only to members of your dedicated group. ```bash sudo visudo ``` Add this line to the file: ```text %sudousers ALL=(ALL:ALL) ALL ``` The `%` prefix indicates this applies to a **group** rather than a single user. According to the repository's README.md, this configuration ensures that only members of `sudousers` may invoke sudo; unauthorized users receive a `sudo: sorry, you are not allowed to ...` error. ### 5. Verify the Configuration Test that authorized users can invoke sudo while unauthorized users are properly blocked. ```bash sudo -l -U alice # Should list allowed commands sudo -l -U charlie # Should report "user NOT in the sudoers file" ``` Confirm group membership with: ```bash getent group sudousers ``` ## Understanding the Sudoers Syntax The entry `%sudousers ALL=(ALL:ALL) ALL` follows a precise privilege specification format. The leading `%` identifies `sudousers` as a group name rather than a username. The first `ALL` specifies the host, the `(ALL:ALL)` allows running commands as any user and any group, and the final `ALL` permits any command. This implementation in `/etc/sudoers` replaces the need for individual user entries, centralizing control through UNIX group membership as implemented in the How-To-Secure-A-Linux-Server guide. ## Key Files and Commands Reference When implementing group-based sudo restrictions, these system files and utilities are critical: - **`/etc/sudoers`**: The central policy file defining who can execute what commands as which users. Always edit with `visudo` to prevent lockouts from syntax errors. - **`/etc/group`**: Contains UNIX group definitions, including your newly created `sudousers` entry. - **`visudo`**: The safe editing command that checks syntax before committing changes to `/etc/sudoers`. ## Summary - **Create a dedicated group** (e.g., `sudousers`) to centralize privilege management and avoid per-user entries in `/etc/sudoers`. - **Use `usermod -a -G`** to add users to the sudo group without overwriting their existing group memberships. - **Always backup `/etc/sudoers`** with `cp --archive` before modifications, and use `visudo` for safe editing. - **Prepend the group name with `%`** in the sudoers file to indicate group membership rather than individual user authorization. - **Verify access** with `sudo -l -U username` to ensure unauthorized users are properly blocked. ## Frequently Asked Questions ### What is the difference between sudo access for users vs groups? Individual user entries require modifying `/etc/sudoers` every time you add or remove an administrator. Group-based access lets you manage membership through standard UNIX tools like `usermod`, keeping the sudoers file static and reducing the risk of syntax errors during routine user management. ### Why must I use visudo instead of editing /etc/sudoers directly? `visudo` validates the sudoers file syntax before saving. If you introduce a typo while manually editing `/etc/sudoers` with a standard text editor, you could lock all users—including root—out of sudo access, potentially requiring single-user mode recovery to fix. ### How do I remove sudo privileges from a specific user? Remove the user from the sudo group using `sudo gpasswd -d username sudousers` or `sudo deluser username sudousers`, depending on your distribution. The change takes effect immediately without needing to edit `/etc/sudoers`. ### Can I restrict sudo to specific commands instead of full access? Yes. Replace the final `ALL` in the sudoers rule with specific command paths. For example, `%sudousers ALL=(ALL:ALL) /bin/systemctl restart nginx` would allow group members to restart only the Nginx service, following the principle of least privilege outlined in the How-To-Secure-A-Linux-Server guide.