What is the difference between adding a user to "sudoers" vs "root" group?

23,989

Solution 1

The 'root group' as in what you would specify in /etc/group is about unix permissions. Every file has user, group, and 'other' permissions. If a file is set such that users in group root can read it, then you can grant a user the ability to read that file by putting the user in group root. Of course then that user can read every file which has the read bit set for group root.

The sudoers file is about running commands with the effective ID of other users. You have more granular control over what commands each user can run, and as as whom. So if you want a user to only be able to run one specific command as root, then you would set that in the sudoers file.

Solution 2

Although the question mentions "Debian Linux server", it is currently tagged with both Debian and Ubuntu. Since information about multiple operating systems seems to be of some interest, I'm going to just ignore the references to specific operating systems entirely, and just describe the most widespread standards.

Groups are listed in /etc/group and there is frequently a group named "root". This file lists the names of groups, and their corresponding "group ID" ("GID") numeric values.

Anyone in a group named "root" will have the ability to read, write, or execute files that have a "group owner" set to the same "group ID" ("GID") as the group named root. So, if a file is owned by "bin:root", and has permissions of "rwxrwx---", then a user in the "root" group will be able to run the file because of the middle set of permissions.

In contrast, the standard set by the "sudo" software is based on the configuration stored in the /etc/sudoers file. In the /etc/sudoers file, Unix-style group names are shown after percent signs, as discussed by sudoers man page (in HTML format): section on "sudoers" file format. So, a reference to %sudoers in the /etc/sudoers file refers to a group named "sudoers" which is in the /etc/groups file.

The default /etc/sudoers file does not contain a reference to a group named "sudoers". Note that I am referring to the real default /etc/sudoers file, which you can view by seeing sudo repository, clicking "browse" in the left frame, then "examples", then "sudoers".

However, many operating systems have a custom /etc/sudoers file installed by default. So it is quite possible that your operating system has special support for a group named sudoers. To understand the exact impact, check out the /etc/sudoers file.

Presumably, what is likely is that if your operating system has a group named sudoers, then a person in that group will be able to elevate permissions using the sudo command. (The recommended way to confirm this would involve checking the /etc/sudoers file.)

When a person elevates their privileges, such a person might need to type in acceptable authentication (a password), or might not need to. Even if they do, after being authenticated, they may have a "token" for some period of time, which will allow them to elevate again without needing to authenticate again (until that period of time is up). This period of time is 5 minutes unless /etc/sudoers specifies something different by using an option called "timeout".

In contrast, a person in the "root" group would not need to type a password to access a file that is owned by the "root" group.

Note that the "sudoers" group might be preferential. By elevating, a person may be able to get full superuser access. (This is typical. The /etc/sudoers file can allow a person to switch to a different user, or to elevate but with restrictions on what command is initially run. Usually, with default/simple configurations, a person who elevates just gets full elevation.) When authenticated as a full superuser, a user is generally not subject to permissions that are based on typical Unix filesystem ownerships (the "owner" and the "group owner" settings). The user may still be subject to other permissions-based limitations, like permissions enforced by the way that a partition was mounted (which is the reason why software won't allow a user to write to a read-only CD-ROM), or another other reasons that a file might not provide permissions (like if a file is locked, indicating that the file is already in use). If a file is owned by:

root:root

and has permissions of:

rwx------

Then a user does not get permissions to the file just because the user is in a group called "root". So, the "root" group can be more convenient (no passwords needed), although it can be more limited. (Or, a group in /etc/sudoers can be more limited, based on how /etc/sudoers is configured.)

Solution 3

First of all, root user is the first user in the sudoers group, right after ubuntu is installed on the machine. Second, root and a superuser (for example Michael) both have the same user id (UID) of 0 which is the ID of superusers. They have the same privileges. Third, the only difference is that a super user has to type sudo command before any command that needs special privileges, but root user doesn't have to. They are different just by name and are recognized namely.

Share:
23,989

Related videos on Youtube

Michael
Author by

Michael

Interests: Android Development, Network/Software Security

Updated on September 18, 2022

Comments

  • Michael
    Michael over 1 year

    I have done some research and in order to allow the user to use the sudo command, you must add them to the "sudoers" group. This gives them root privileges as long as they enter in root's password. But I have also come across examples of people adding the user the the "root" group instead of the "sudoers" group. My question is are there different privileges given between the two groups, and if so what are they and what are the benefits of both techniques?

    I am using a Debian Linux server.

    Thanks

    • Ramhound
      Ramhound about 8 years
      One makes the user with the ability to elevated their permission, the other, makes the user's permissions the highest permission possible always.