I will try to explain my situation first. I am currently running 6 virtualized Debian servers on a ESXi host machine. The virtual servers where installed with a Debian Linux 6 (Lenny).

Recently I updated the servers to debian Wheezy

root@ares> lsb_release -a                                                                                                    /home/vincent
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.1 (wheezy)
Release:        7.1
Codename:       wheezy

it has come to my attention that since this upgrade the 'sudo' command is displaying weird behaviour. Actually, it seems to have no effect at all. I checked the /etc/visudo file and everything seems ok. Sudo also asks for my password but then does not seem to run things as root. An example is the 'ifconfig' command:

user@ares> ifconfig 
zsh: command not found: ifconfig
[127] user@ares> sudo ifconfig
sudo: ifconfig: command not found
[1] user@ares> sudo su
output shows    

anyone who can help me out here?

  • Check your PATH. Aug 2 '13 at 6:37
  • @MichaelHampton thx. This seems to be the issue. Could you post this as answer? Mystery tough how my path has changed after the upgrade...
    – Goez
    Aug 2 '13 at 6:41

Your PATH probably differs between your normal user and the root user, likely missing directories such as /sbin and/or /usr/sbin where administrative utilities like ifconfig normally live.

  • I think the OP is complaining that sudo as configured no longer changes the PATH for sudo commands. If that's right, your answer isn't, though it points in the right general direction for finding the issue.
    – mc0e
    Oct 19 '14 at 12:46

Michael's answer is correct, but I wanted to add a comment:

It is not mandatory to add administrative commands' path (/sbin, /usr/sbin, /usr/local/sbin) to an unprivileged user, as long as the secure_path directive is configured in /etc/sudoers on in your LDAP server, if you use an LDAP backend:

$ ip a s
-rbash: ip: command not found

$ sudo ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 1000
    link/ether 00:0c:29:57:80:d9 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0

$ echo $PATH

$ sudo -l | awk '$0~/secure_path/ {print $1}'

Check man 5 sudoers for further reference on secure_path (also of interest are exempt_group and env_reset).

 secure_path   Path used for every command run from sudo.  If you don’t trust the people running sudo to have a sane PATH environment variable you may want to use this.  Another use is if you want to
               have the “root path” be separate from the “user path”.  Users in the group specified by the exempt_group option are not affected by secure_path.  This option is not set by default.
  • Very useful, and much better than the answer marked as correct. only thing is that man sudoers(5) is not a valid command. Maybe different people do things differently(?), but I reckon if you're going to refer to sudoers(5) you should talk about the "sudoers(5) man page", not man 5 sudoers. Nitpicky to be sure. Edited.
    – mc0e
    Oct 19 '14 at 12:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.