Re: [PATCH] tests: adjust PATH to include /usr/sbin for filefrag-using tests

[Bob Proulx]

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