Re: Adding . and /usr/local/bin to PATH raises security issue??
Date: Sun, 22 Feb 2004 18:30:07 GMT
In article <RdpZb.884$GX6.email@example.com>, Doug O'Leary wrote:
> In article <firstname.lastname@example.org>, Forte Agent wrote:
>> I heard adding "." and "/usr/local/bin" to PATH raises security issue.
>> Is that true? Why? Thank you in advance.
> As Nick mentioned in his followup, the danger is in replacing
> commands if the . and /usr/local/bin show up in before standard
> system directories. ...
> For instance, assume you have /usr/local/bin anywhere in the path
> and that it's 777 permissions (always a bad idea, but standard
> w/HPUX). ...
I'm astounded that HPUX would do something like that. Surely an
"untrusted" directory should not be on anyone's path. So giving write
permission on /usr/local/bin would make that directory useless.
Beyond such nonesense, however, one of the major uses of a /usr/local/bin
is to place local variants of commands that may well be part of a standard
distribution in /usr/bin, and that a particular administrator wants the
variant to be used in normal circumstances rather than the standard
version--therefore, /usr/local/bin should be before /usr/bin in the search
path. /usr/local/sbin is normally ahead of /usr/sbin, for the same
Dave Brown Austin, TX
- Re: So how is this dangerous
... if the standard is danger -- not what you or I think the standard ... should be -- ignoring whether it is Steyn or Harbhajan is beyond ... Who said the standard is danger? ...
- Re: Library functions
... Many environments do in fact allow Standard libarary ... it would be folly to replace malloc() without replacing free() ... But not all environments can offer this capability. ...
- Re: global variable name conflict with standard header
... > for the benefit of dumb optimizers who can now inline any standard ... replacing calloc() and reallocand free, ... the programmer stays on *this* side and the implementor stays ... to trespass on the implementor's turf by redefining longjmp. ...
- Re: Adding . and /usr/local/bin to PATH raises security issue??
... > is to place local variants of commands that may well be part of a standard ... I normally lock the directory down and put it in my personal path. ...
- Re: Verbose functional languages?
... the situation can be much worse than not having a standard. ... Of course, for printf and the like, that's less of an issue. ... These guys have been rooting out stuff, rewriting it, and replacing it with better implementations, details, and even concepts, sometimes even replacing entire subsystems. ... First, the argument that control-code style printf is what programmers expect and know would be strong if it were valid; C++ stdio already deviates from it, so you don't erect a barrier if you deviate, too. ...