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))
sudo
improves safety/security by providing accountability, and privilege separation.
Imagine a system that has more than one person performing administrative tasks. If a root
login account is enabled, the system will have no record/log of which person performed a particular action. This is because the logs will only show root
was responsible, and now we may not know exactly who root
was at that time.
OTOH, if all persons must login as a regular user, and then sudo
for 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 the sudoers
file.
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 sudoers
file are set to ALL
(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; sudo
is most certainly not a panacea. At the end of the day, I feel that like many other safeguards we put in place, sudo
helps keep honest people honest - it's less effective at keeping dishonest people at bay.
Best Answer
If you have a similar system that you can use as a guide to see what the correct ownership for all of the files is, then you can boot into rescue mode, drop to a root shell, and manually restore the correct ownership to all of the files in
/usr
.The quickest way may be to reinstall your OS or restore from backup.
In Ubuntu or similar, then there is no root password by default (the account is disabled), which is why you can't
su
.