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
signature.asc
Description: Digital signature