Re: root path change
On 08/30/2011 11:56 AM, Bob Proulx wrote:
Paul Scott wrote:
Bob Proulx wrote:
What is your path after the sudo? This is easy to tell with:
sudo printenv PATH
I see this on my Sid machine:
$ sudo printenv PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I get:
sudo printenv PATH
/usr/local/bin:/usr/bin:/bin:/usr/games
That is definitely bad and needs to be fixed. This is probably going
to bite a lot of people. List, listen up, I predict this to be a
recurring theme for a while. :-)
Thanks! I have now purged and reinstalled sudo and everything seems to
be working as I was used to. Things like sudo ifconfig now work again!
I have libselinux1 installed which a wild guess on my part says
could be related.
I have that installed too, it is part of a default installation. It
is not the problem.
And then you should look at 'sudo -l' to see what it says. There
should be clues there.
sudo -l
Matching Defaults entries for paul on this host:
env_reset
I see no clues.
I do. It gave me the hint to know what is happening. Your sudo flags
say "env_reset" but do not say secure_path. That tells me that
secure_path is not set for you. But it it is set by default. It is
for me. That is why I didn't see it initially. But then the light
bulb came on for me and I see the problem you have hit.
Due to the new sudo package it also pulled in a new /etc/sudoers
conffile with it. The new conffile defaults secure_path on with:
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
> But you almost certainly had your own custom /etc/sudoers file in
place previous to this upgrade. When it upgraded, did you get the
dpkg dialog box for upgrading conffiles asking you if you wanted to
install the package maintainer's version or keep your own version or
show a diff of the files?
Yes, I took the defaults. All is well now.
Configuration file `/etc/sudoers'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** sudoers (Y/I/N/O/D/Z) [default=N] ?
I am sure you handled that question in the way many people would
handle it and say 'N', keep my file, I have customized it. But that
is wrong in this case. (Not trying to sound harsh here. It is a
trap. Most people would say 'N' here. But that is the problem.)
If you said 'N', keep your existing file then that is the root cause
of the problem. Your old file didn't set secure_path but by default
secure_path was already on in the previous version whether you set it
on or not. So effectively by keeping your previous conffile you
changed from having secure_path on to having secure_path off.
A better answer would have been to 'D' show the differences between
and then manually merge the old and new configuration. During the
merge you would have caught the incoming new presence of secure_path
in the new maintainer's version of the file and then added it to your
file. If you haven't deleted it then the new version of the
maintainer's file should still be present on your machine at
/etc/sudoers.dpkg-new where you can examine it and merge it into the
old file.
So the best answer for you to solve this problem is to edit your
/etc/sudoers file and add that line. Look at the sudoers.dpkg-new for
the right syntax.
Some observant readers may then ask, "Why didn't I get hit by this too?
Surely I had a customized /etc/sudoers file." Well actually no I
didn't. I have a customized /etc/sudoers.d/local-sudoers file instead
just to avoid this kind of problem. By keeping my customized rules in
the /etc/sudoers.d/ directory it means that I never have a modified
conffile and therefore am never presented with the dialog box during
package upgrade. When I upgraded to the new package my /etc/sudoers
was unmodified and so was upgraded to the new version by default and I
got the new setting of secure_path newly set there without doing
anything.
Bob
P.S If you haven't done this for a while then you should look at all
of the other configuration files on your machine and do any merging
or cleaning that may be needing to be done but hasn't been done.
find /etc -name '*.dpkg*'
I did find two.
Thanks!
I do hope this helps others.
Paul
Reply to: