Jim Meyering wrote: > The point is that the separation is not clear. > Even /sbin programs like mkfs.* can be useful to non-root users. > I use a few of those in parted tests. > Also, ifconfig is useful to non-root users, yet resides in /sbin.
I am sure that you like me always add /usr/local/sbin:/usr/sbin:/sbin to your PATH as a normal non-root user. This shields us from most of those problems. And sometimes hides the problem. > Thus, by omitting /sbin and /usr/sbin, that version of sudo is > causing trouble. Fedora made the same change to sudo, but ended > up reverting it due to all of the trouble it caused. The upstream sudo has been making some incompatible changes with regards to PATH specifically around secure_path (and running configure with --with-secure-path). This has slowly been rippling down. I apologize in advance but this is going to be a Debian centered view. But as they say, write what you know. For a long time Debian used --with-secure-path and a compiled in secure_path value. Apparently the problem was that people who wanted to NOT turn on secure_path had no way to do so[1]. And, as I read the changes, this was addressed by flipping things the opposite way now, not using --with-secure-path, and requiring those who DO want secure_path to now always include a secure_path setting in the sudoers configuration file /etc/sudoers and /etc/sudoers.d/*. In Debian the default packaged version of the sudoers file was changed. That's fine. But since sudoers is almost always customized it means that if you upgrade bug keep your previous sudoers configuration verbatim and miss making that change it means that secure_path is then lost when upgrading to the new version of sudo. This has caused some thrash in Debian Sid/Wheezy recently. The current best practice is to include a secure_path setting in the sudoers configuration. Bob [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=85123
