Michael wrote:
> Is there any (significant) difference between editing (adding a user
> to) the _/etc/sudoers_ file and adding a person to the _admin
> group?_ Am I comparing apples and oranges?
There is no default "admin" group. I think you are referring to the
"sudo" group. (There is an "adm" group useful for read-only access to
/var/log files. But that is something different.)
Assuming "sudo" where you said "admin" above then:
No. The end result is the same. Root is uid 0 the superuser. It
doesn't matter how you get there. Both give you the same result.
There are (not significant) differences in system management by using
the two methods. Let's walk through the major cases.
================================================================
1. Traditional /etc/sudoers entry.
alice ALL=(ALL:ALL) ALL
This allows user alice full root access using sudo. Sudo will ask for
alice's password (not root's password, alice's password) and then will
alow any command. All good.
Because the /etc/sudoers file is modified then upon every upgrade to
the sudo package you will be offered to select the package version or
your version or see the diffs or merge the two. It is necessary that
you always carefully merge your local additions with the upstream
package config version.
Let's say that you select your version. This causes problems because
between Squeeze 6 and Wheezy 7 sudo moved secure_path from configure
to default /etc/sudoers (Bug#85123, Bug#85917). This means you will
have your PATH instead of the sudo PATH and commands won't be found
unless you give the full path to them or set PATH specifically. This
has caused many problems and discussion on this list and a NEWS item
was added for it (Bug#639841).
So you want to take the package version so that you get the new
sudoers secure_path configuration. Or another new configuration that
appears in the future. But if you do that then it will remove the
alice entry from the /etc/sudoers file. If alice is using sudo
command by command to do the upgrade then this would lock alice out of
the machine because after the upgrade there wouldn't be a sudo entry
there anymore.
Therefore the only correct answer is to merge the file right then and
there. Merge the local customizations into the upstream package
version of the file.
Also new is the "#includedir /etc/sudoers.d" entry. It includes all
fragments in that directory. Again it is new and only appears in the
new package version. You want it. But if you haven't had it
previously then missing it won't break anything.
There isn't anything wrong with the above. But now that /etc/sudoers
is a conffile the handling of it is very annoying.
================================================================
2. Debian specific feature. Add the user to the "sudo" group.
# adduser alice sudo
This allows user alice full root access using sudo. Sudo will ask for
alice's password (not root's password, alice's password) and then will
alow any command. All good.
That configuration is in /etc/group which is not affected by package
conffiles. With that it is likely that the admin upgrading will not
need any configuration changes to /etc/sudoers. If you never make any
local customizations there then there is no need to merge. Avoiding
the need to merge that file is convenient. Meaning that upgrades are
less tedious, less questions, more automated and Just Work.
================================================================
3. New /etc/sudoers.d/* include fragment.
alice ALL=(ALL:ALL) ALL
This allows user alice full root access using sudo. Sudo will ask for
alice's password (not root's password, alice's password) and then will
alow any command. All good.
Instead of using /etc/sudoers put that line in /etc/sudoers/local or
some such name. That will be included automatically. Because it is a
local name and isn't modifying the conffile /etc/sudoers again it
won't be different for the purposes of the package manager. Upgrades
won't ask any questions and will be hands-off. Meaning that upgrades
are less tedious, less questions, more automated and Just Work.
But Squeeze 6 didn't have the "#includedir" option. That is only
available in Wheezy 7. You can't use it until after an upgrade to
Wheezy 7. But once there and moving forward this is a reasonable
compromise. It is upstream standard.
================================================================
Does that explain things?
Bob
Attachment:
signature.asc
Description: Digital signature