2

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
root@ares>ifconfig  
output shows

anyone who can help me out here?

Improve this question
2
  • Check your PATH.
    – Michael Hampton
    Aug 2, 2013 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, 2013 at 6:41

2 Answers 2

Reset to default
5

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.

Improve this answer
1
  • 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, 2014 at 12:46
2

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 127.0.0.1/8 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 172.22.197.38/24 brd 172.22.197.255 scope global eth0

$ echo $PATH
/home/dawud/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin

$ sudo -l | awk '$0~/secure_path/ {print $1}'
secure_path=/bin\:/usr/bin\:/sbin\:/usr/sbin\:/usr/local/bin\:/usr/local/sbin

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.
Improve this answer
1
  • 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, 2014 at 12:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .