FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 08-30-2011, 05:43 PM
Camaleón
 
Default root path change

On Tue, 30 Aug 2011 10:02:58 -0700, Paul Scott wrote:

> About a week ago 'sudo aptitude' stopped working because /sbin and
> /usr/sbin are no longer on the path. Is this possible a recent security
> improvement? Aptitude works fine if I use "su -" instead of sudo.

Hummm... the change seems to be listed here:

http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_1.8.2-1/changelog

* move secure_path from configure to default sudoers, closes: #85123,
85917

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.08.30.17.43.16@gmail.com">http://lists.debian.org/pan.2011.08.30.17.43.16@gmail.com
 
Old 08-30-2011, 06:02 PM
David Goodenough
 
Default root path change

On Tuesday 30 Aug 2011, Paul Scott wrote:
> Hi,
>
> I'm running sid.
>
> I have found several partial answers with Google but nothing conclusive.
>
> About a week ago 'sudo aptitude' stopped working because /sbin and
> /usr/sbin are no longer on the path. Is this possible a recent security
> improvement? Aptitude works fine if I use "su -" instead of sudo.
>
> Thanks for any information,
>
> Paul Scott

try:-

sudo -i aptitude

which simulates a logon as root and therefore gets the right path.

David


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201108301902.24681.david.goodenough@btconnect.com" >http://lists.debian.org/201108301902.24681.david.goodenough@btconnect.com
 
Old 08-30-2011, 06:16 PM
Bob Proulx
 
Default root path change

Camaleón wrote:
> Paul Scott wrote:
> > About a week ago 'sudo aptitude' stopped working because /sbin and
> > /usr/sbin are no longer on the path. Is this possible a recent security
> > improvement? Aptitude works fine if I use "su -" instead of sudo.

But surely aptitude is in /usr/bin/aptitude and not /usr/sbin/aptitude?

I tested this a moment ago on an up to date Sid machine and sudo
worked okay to find aptitude in /usr/bin/aptitude for me.

> Hummm... the change seems to be listed here:
> http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_1.8.2-1/changelog
> * move secure_path from configure to default sudoers, closes: #85123, 85917

But default secure_path is
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
and so should definitely find aptitude in the path in /usr/bin.

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

And then you should look at 'sudo -l' to see what it says. There
should be clues there.

Bob
 
Old 08-30-2011, 06:19 PM
Paul Scott
 
Default root path change

On 08/30/2011 10:43 AM, Camaleón wrote:

On Tue, 30 Aug 2011 10:02:58 -0700, Paul Scott wrote:


About a week ago 'sudo aptitude' stopped working because /sbin and
/usr/sbin are no longer on the path. Is this possible a recent security
improvement? Aptitude works fine if I use "su -" instead of sudo.

Hummm... the change seems to be listed here:

http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_1.8.2-1/changelog


I appreciate all that you do on this list!!

Thanks for the reply and for your much greater familiarity with this.
From the error messages I wasn't thinking that sudo was the problem and
I definitely don't look at the changelogs that often. As you know there
are hundreds of updates to sid every week. I have been using sid for at
least 8 years and have missed this. I've been on Debian User for about
that long but am a long way from seeing most of what goes by.



* move secure_path from configure to default sudoers, closes: #85123,
85917


I see that secure_path has been around for over 10 years. I was not
familiar with it. None of my reading from the above and related
searches tells me whether I should be using sudo for aptitude and if
there is a secure way to do this.


Thanks for any further help or references,

Paul




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E5D29A6.5040703@ultrasw.com">http://lists.debian.org/4E5D29A6.5040703@ultrasw.com
 
Old 08-30-2011, 06:31 PM
Paul Scott
 
Default root path change

On 08/30/2011 11:16 AM, Bob Proulx wrote:

Camaleón wrote:

Paul Scott wrote:

About a week ago 'sudo aptitude' stopped working because /sbin and
/usr/sbin are no longer on the path. Is this possible a recent security
improvement? Aptitude works fine if I use "su -" instead of sudo.

But surely aptitude is in /usr/bin/aptitude and not /usr/sbin/aptitude?


Sorry I didn't supply enough info. sudo aptitude runs aptitude but
aptitude dies at trying to update anything and gives:


dpkg: warning: 'ldconfig' not found in PATH or not executable.
dpkg: warning: 'start-stop-daemon' not found in PATH or not executable.
dpkg: error: 2 expected programs not found in PATH or not executable.
Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and
/sbin.


Of course, see Cameleon's reply.


I tested this a moment ago on an up to date Sid machine and sudo
worked okay to find aptitude in /usr/bin/aptitude for me.


Hummm... the change seems to be listed here:
http://packages.debian.org/changelogs/pool/main/s/sudo/sudo_1.8.2-1/changelog
* move secure_path from configure to default sudoers, closes: #85123, 85917

But default secure_path is
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
and so should definitely find aptitude in the path in /usr/bin.

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

I have libselinux1 installed which a wild guess on my part says could be related.



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

User paul may run the following commands on this host:
(ALL) ALL

I see no clues.

Thanks,

Paul




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E5D2C6D.9040806@ultrasw.com">http://lists.debian.org/4E5D2C6D.9040806@ultrasw.com
 
Old 08-30-2011, 06:56 PM
Bob Proulx
 
Default root path change

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. :-)

> 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?

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*'
 
Old 08-30-2011, 07:25 PM
Paul Scott
 
Default root path change

On 08/30/2011 11:02 AM, David Goodenough wrote:

On Tuesday 30 Aug 2011, Paul Scott wrote:

Hi,

I'm running sid.

I have found several partial answers with Google but nothing conclusive.

About a week ago 'sudo aptitude' stopped working because /sbin and
/usr/sbin are no longer on the path. Is this possible a recent security
improvement? Aptitude works fine if I use "su -" instead of sudo.

Thanks for any information,

Paul Scott

try:-

sudo -i aptitude

which simulates a logon as root and therefore gets the right path.


Thanks! See the reply I am about to make to Bob.

Paul




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E5D3942.7000407@ultrasw.com">http://lists.debian.org/4E5D3942.7000407@ultrasw.com
 
Old 08-30-2011, 07:32 PM
Paul Scott
 
Default 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




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Archive: 4E5D3AC0.4020603@ultrasw.com">http://lists.debian.org/4E5D3AC0.4020603@ultrasw.com
 
Old 08-30-2011, 07:41 PM
Walter Hurry
 
Default root path change

On Tue, 30 Aug 2011 12:32:16 -0700, Paul Scott wrote:

> Thanks! I have now purged and reinstalled sudo and everything seems to
> be working as I was used to.

You didn't need to do that. All you needed to do was to edit /etc/sudoers
as Bob suggested.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: j3jecf$89k$1@dough.gmane.org">http://lists.debian.org/j3jecf$89k$1@dough.gmane.org
 
Old 08-30-2011, 07:56 PM
Bob Proulx
 
Default root path change

Bob Proulx wrote:
> Paul Scott wrote:
> > 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. :-)

As an fyi I filed this bug against sudo version 1.8.2-1 in Sid
requesting a NEWS entry be added to accompany this secure_path
behavior change.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639841

Bob
 

Thread Tools




All times are GMT. The time now is 01:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org