On Fri, 28 Sep 2007 20:05:52 +0200 (CEST)
Magnus Eriksson <magetoo@fastmail.fm> wrote:

> On Fri, 28 Sep 2007, John Nemeth wrote:
> 
> > }    Having a suid root program exploited to create the directory,
> > or change } the permissions of it -- *that* security problem.
> 
> >     If an suid root program can be exploited in such a way, it can
> > most likely cause all sorts of other problems.
> 
>    Maybe such a buggy program could, maybe not.  But are you then
> saying that this particular hole should therefore *not* be fixed?
> 
>    Seems kinda obvious to me that when you see a potential security 
> problem, you fix it right away, no matter how unlikely it seems it
> might be exploited.  That just the way you do things.
> 
I do not agree that it's a hole.  I think it's correct to
include /usr/local in default paths -- /usr/local/bin for
execution, /usr/local/lib for linking, /usr/local/include for
compiling, etc.  I regard it as necessary for running production
systems where I want to be able to do "vendor" upgrades without
interfering with locally-developed or installed code.
> 
> > This is a pretty trivial concern.
> 
> > }    I don't know exactly in which "various default
> > PATHs" /usr/local is
> >
> >    The ones in /etc/skel/*, which are the files used to populate a
> > user's home directory when you do 'useradd -m ...'.  Also, the ones
> > in /root/.*.
> 
>    So in the default PATH for all users?  Including root?  Wow.
> 
If you do 'useradd -m root', yes.  Given that root already exists --
with a .profile, etc., that doesn't come from there -- I'd call that a
non-issue. 



		--Steve Bellovin, http://www.cs.columbia.edu/~smb