Tony van der Hoff wrote:
> Klaus wrote:
> > Tony van der Hoff wrote:
> >> Can anyone please tell me where $PATH is set for sudo with wheezy?
> >>
> >> It seems that my sudoer has no access to /sbin on one of my machines,
> >> but does on others, with a seemingly identical installation.
> >>
> >> Thanks, Tony.
> >
> > Does your sudoers file set the secure_path variable? From man sudoers:
>
> Thanks for the reply, Klaus. No, it doesn't. Furthermore, sudoers is
> identical on the failing system to that on the working system.
This is one of those gotchas that was released for Wheezy 7.
Pre-Wheezy there was no secure_path line. In version 1.8.2 the
following change was made:
sudo (1.8.2-1) unstable; urgency=low
The sudo package is no longer configured using --with-secure-path.
Instead, the provided sudoers file now contains a line declaring
'Defaults secure_path=' with the same path content that was previously
hard-coded in the binary. A consequence of this change is that if you
do not have such a definition in sudoers, the PATH searched for commands
by sudo may be empty.
Using explicit paths for each command you want to run with sudo will work
well enough to allow the sudoers file to be updated with a suitable entry
if one is not already present and you choose to not accept the updated
version provided by the package.
Here are two additional references.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639841
https://wiki.debian.org/sudo
Most people hit this when the upgraded from Squeeze 6 to Wheezy 7.
The mailing list had many reports of this problem around that time.
Anyone who has modified their /etc/sudoers file will need to take the
new distributed version of the /etc/sudoers file and merge in their
local changes.
Specifically they will need to take the secure_path line from the new
file and put that line in their file. Some people do install sudoers
and then add themselves to the sudoers group and therefore do not need
to modify the file. But most of us long time users usually have a
modified version of the file and will need to ensure that secure_path
is added to our files.
Let me share my personal wheezy notes on this.
After complaints in Bug#605130 that found during testing package
purges that sudo didn't remove /etc/suders (who ever purges sudo in
a real system?) the file was changed to a conffile. Upgrades now
mean this file is offered to the user for handling at upgrade time.
But along with this comes /etc/sudoers.d/ which is where local
content can be placed so as to avoid future upgrade thrash.
/etc/sudoers should now contain a secure_path statement due to
changes in the compiled in default now requiring it. A secure_path
line must now be added to our config where it was not needed before.
So on the one hand you can now move your entire configuration file
into /etc/sudoers.d/local-sudoers and avoid thrashes from future
package upgrades. (Were you ever thrashed by past upgrades? Yes,
once when the "env_keep += HOME" became required.) But then you lose
the ability to easily edit the file with visudo. That is annoying
for random systems not using an infrastructure for system
configuration. So I will probably continue to use /etc/sudoers on
most systems, push through this thrash, and just keep hitting the
thrash in the future.
Bob
Attachment:
signature.asc
Description: Digital signature