On Tue, Jan 13, 2004 at 08:43:20AM -0300, Alexandre Strube wrote:
> > > But by commenting out the uid check, you're adding /sbin, /usr/sbin, and
> > > /usr/local/sbin, to the environment of all users on the system. My
> > > understanding is that this is a no-no when it comes to securing the
> > > system.
....
> This is not true - on every rehat system since 8.0 I've been doing this.
> No machine had reduced funtionality because of it. In fact, the opposite
> happened. Try for yourselves, then tell me.
As long as you get the search order correct....
/usr/bin/halt
/sbin/halt
There are a number of files with duplicate names where the search
order is important. As long as the correct one is found first things
are cool.
For example /usr/bin/halt should be found first so "consolehelper" is run and
pam checks/magic take place then /sbin/halt ....
Since, any user can give an absolute path name there is no security
problem with path/PATH that does not exist for the nimble fingered
user. Of interest access and permissions given via pam setups can be
missed if the path is wrong. This means that a trusted user with a
bad PATH/path may not be able to act as you trust him/her to do.
>From the consolehelper man page:
"It is intended to be completely transparent. This means that the user
will never run the consolehelper program directly. Instead, programs
like /sbin/shutdown are paired with a link from /usr/bin/shutdown to
/usr/bin/consolehelper. Then when non-root users (specifically, users
without /sbin in their path, or /sbin after /usr/bin) call the "shut-
down" program, consolehelper will be invoked to authenticate the action
and then invoke /sbin/shutdown. (consolehelper itself has no priv-
iledges; it calls the userhelper(8) program do the real work.)"
BTW: I use path/PATH to remind myself that csh users may have had some special
considerations with $path and $PATH.
--
T o m M i t c h e l l
mitch48-at-sbcglobal-dot-net
