Then answer is that sudo has a bug. First, the workaround: I put this in my /etc/sudoers.d/zabbix file:
zabbix ALL=(root) NOPASSWD: /bin/env SHELL=/bin/sh /usr/local/bin/zabbix_raid_discovery
and now subcommands called from zabbix_raid_discovery work.
A patch to fix this will be in sudo 1.8.15. From the maintainer, Todd Miller:
This is just a case of "it's always been like that". There's not
really a good reason for it. The diff below should make the behavior
match the documentation.
- todd
diff -r adb927ad5e86 plugins/sudoers/env.c
--- a/plugins/sudoers/env.c Tue Oct 06 09:33:27 2015 -0600
+++ b/plugins/sudoers/env.c Tue Oct 06 10:04:03 2015 -0600
@@ -939,8 +939,6 @@
CHECK_SETENV2("USERNAME", runas_pw->pw_name,
ISSET(didvar, DID_USERNAME), true);
} else {
- if (!ISSET(didvar, DID_SHELL))
- CHECK_SETENV2("SHELL", sudo_user.pw->pw_shell, false, true);
/* We will set LOGNAME later in the def_set_logname case. */
if (!def_set_logname) {
if (!ISSET(didvar, DID_LOGNAME))
@@ -984,6 +982,8 @@
if (!env_should_delete(*ep)) {
if (strncmp(*ep, "SUDO_PS1=", 9) == 0)
ps1 = *ep + 5;
+ else if (strncmp(*ep, "SHELL=", 6) == 0)
+ SET(didvar, DID_SHELL);
else if (strncmp(*ep, "PATH=", 5) == 0)
SET(didvar, DID_PATH);
else if (strncmp(*ep, "TERM=", 5) == 0)
@@ -1039,7 +1039,9 @@
if (reset_home)
CHECK_SETENV2("HOME", runas_pw->pw_dir, true, true);
- /* Provide default values for $TERM and $PATH if they are not set. */
+ /* Provide default values for $SHELL, $TERM and $PATH if not set. */
+ if (!ISSET(didvar, DID_SHELL))
+ CHECK_SETENV2("SHELL", runas_pw->pw_shell, false, false);
if (!ISSET(didvar, DID_TERM))
CHECK_PUTENV("TERM=unknown", false, false);
if (!ISSET(didvar, DID_PATH))
Because you can define a specific set of commands in /etc/sudoers that newuser is limited to running with elevated privileges. Ideally you find out what minimum commands are needed and limit it to that. Don't allow the account to sudo all commands as root if you can help it.
Next, you do not permit root to login via ssh. (/etc/ssh/sshd_config, set PermitRootLogin no). You always ssh login as yourself, not root, then just use sudo as needed.
Best Answer
sudoimproves safety/security by providing accountability, and privilege separation.Imagine a system that has more than one person performing administrative tasks. If a
rootlogin account is enabled, the system will have no record/log of which person performed a particular action. This is because the logs will only showrootwas responsible, and now we may not know exactly whorootwas at that time.OTOH, if all persons must login as a regular user, and then
sudofor privilege elevation, the system will have a record of which user account performed an action. In addition, privileges for that particular user account may be managed and allocated in thesudoersfile.To answer your question now, a hacker that compromises one user account will get only those privileges assigned to that account. Further, the system logs will (hopefully) have a record showing which user account was compromised. OTOH, if it's a simple, single-user system where the privileges in the
sudoersfile are set toALL(e.g.%sudo ALL=(ALL:ALL) ALL), then the advantages of accountability, and privilege separation are effectively neutered.Finally, in regard to the advantages of
sudo, the likelihood is that a knowledgeable hacker may also be able to cover his tracks by erasing log files, etc;sudois most certainly not a panacea. At the end of the day, I feel that like many other safeguards we put in place,sudohelps keep honest people honest - it's less effective at keeping dishonest people at bay.