On 2013-11-09 at 15:07 +0000, Edward Ned Harvey (lopser) wrote:
> Leaving sbin off the path doesn't improve security or reliability.
Not everything is around security. The issue is around usability, and
whether people need more commands littering their path if they can never
use them. What's changed is a shift from multi-user systems to Unix
being a personal OS, so it's more normal for the person logged in to
_have_ sudo access, and be able to do things with it.
> There is no general way for /etc/bashrc to make the distinction
> between users who can do something in sudo or not, and add sbin to the
> path of sudo users.
If you mean, "can interrogate sudo to find out", then no, `sudo -l`
can be set to require authentication, it's not reliable. But that's a
distraction.
In _practice_, the desktop user is a member of a _group_ identifying
them as the system's main user. It might not be "wheel" any more, but
each OS variant will have some such group ("staff", "admin", whatever).
And your shell startup certainly _can_ interrogate the list of groups
which the current user is a member of. It doesn't even require a
fork/exec to interrogate: bash has ${GROUPS[@]}. So it would be easy to
make sure that a desktop OS setup can provide /sbin in the $PATH for
those users, but not anyone else.
But this creates complexity, with another thing which changes, and
confuses people, creating a support burden.
So they adhere to KISS.
-Phil
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
