On 7/13/07, Woodchuck <[EMAIL PROTECTED]> wrote:
On Fri, 13 Jul 2007, Philip Guenther wrote:
...
> Why do people think that hardcoding the paths to normal programs is a
> good thing? Why not just say "formail" and let the shell do the work?
Sometimes users do nutty things with aliases. Then they need to
undo the nuttiness when they need default behavior. Even worse is
the sort who defines new meanings for common commands and places
them "high" in the PATH, or defining nutty shell functions named
for standard commands. (Such as the nutty implementation of "undelete"
functionality through a redefinition of rm to a mv of a file to a
"hidden" directory.)
If someone wants to provide undelete by putting their own version of
'rm' early in their path, that's their right and any consequences are
their own to deal with. A complaint that "your script used my version
of 'rm'!" is properly responded to by saying "you're welcome!".
That goes for a lot of possible nuttiness: UNIX has always provided
users all the rope they wanted, whether for holding up sails or
hanging themselves.
Yes, issues may arise when there are programs running with elevated
privileges. For example, procmail contains a bunch of paranoia about
file and directory ownership because it is often running as users that
don't even know it exists, such as when it is configured as the local
delivery agent. Once procmail decides that your $HOME/.procmailrc can
be trusted, however, that rcfile is perfectly free to pull in or run
whatever it wants, safe or not. Similarly, procmail carefully cleans
the environment whenever it's run with options that could make it
change its uid or gid, as it supports being installed setuid root or
setgid mail, but your rcfile can load the environment back up with
whatever scary hooks you prefer (LD_PRELOAD? Sure!).
One good bit of news is that $ENV files will no longer be an issue for
non-interactive programs as of OpenBSD 4.2, as the ksh in CVS no
longer sources your $ENV file when non-interactive. That's a Single
Unix Spec requirement, so other systems are (oh so slowly) moving that
way too. That means aliases won't bite scripts unless the scripts go
out of their way to be targets.
The default ksh.kshrc shipped with OpenBSD contains "nutty" aliases:
...which will only be experienced by users that have it manually
enabled in their .profile, either by themselves or their admins. And
even for them it won't be an issue after 4.2 or on other systems that
comply with the SUS requirements on the shell.
On a multiuser system, even one with one human user, uncertainty
arises about what flavor of nuttiness is in play for each user in
all possible contexts. (Is my user name that invokes ksh subject
to the same nuttiness as the one that invokes zsh or csh?)
Why would your shell matter? It's not like scripts are run by your
current shell (again, unless they make themselves a target).
Also, slipping a dubious substitution for a system command into
another user's ~/bin, on ill-administered or "trusty" systems, can
lead to various forms of good-natured, puckish mischief. (Suppose
I can substitute an arbitary executable named "vi" or "rm" into
your ~/bin.)
Setting a PATH and using fully qualified path names for utilities
may be classified as a sort of prudent practice. Whether it is
best practice I do not judge.
If you have write access a directory that's early in my path, then I
have ceded to you control of my account. I fail to see how using full
paths for only some programs (not all) and only in scripts (not in
interactive shells) is going to fix that. Darn, you can't slip in via
formail because I used $FORMAIL, so you'll have to do it via the plain
'rm' or 'cat'. Or better, put that evil version of 'tset' or 'stty'
in my path and wait for me to log in.
(Setting PATH or using full paths _is_ valid, in my opinion, for
dealing with systems where incompatible versions of system utilities
are present, such as Solaris with its ancient awk and
/usr/ucb/{df,ps,chown,...}. <shakes fist at Sun>. That's a matter of
porting rather than security, as it is aimed at the brokenness that
has been encountered and not as an attempt to make something work when
the user can't be trusted.)
Philip Guenther
