httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: Deja vu
Date Sat, 06 Jan 2001 22:46:41 GMT
rbb@covalent.net wrote:
> 
> > > Ah, I see the problem.  It isn't apr_home_dir that would cause the
> > > problem.  The problem is that under the covers apr_home_dir calls
> > > getpwnam, which access the password database using static memory in the C
> > > Run-Time.  We can put locks around getpwnam in apr_home_dir, and this will
> > > ensure that multiple calls to apr_home_dir won't affect each other.
> > >
> > > The problem comes in when some other C Run-Time function that access the
> > > password database is called.  These potentially uses the same static
> > > memory in the C Run-Time that getpwname uses, so we might overwrite the
> > > data that getpwnam wants.
> > >
> > > The locks that we put around getpwnam in apr_home_dir won't protect us if
> > > some other part of Apache calls into the C Run-Time's password db
> > > accessors without locking the mutex.
> >
> > ??? But surely they shouldn't do that, coz they should call APRs
> > routines for doing it?
> 
> But, the only APR function we have that deals with the password database
> in apr_home_directory.  We decided when we first hit this issue, that
> we wouldn't create all the other functions until we needed them.  In the
> long term though, yes you are correct that if the only access to the
> password database is through APR, we could solve all the problems.  I have
> a hard time believing we can rely on programmers to accept that though.
> 
> > Actually, after contemplation, I thought the deal was that although you
> > could lock getpwnam (and anything else that might obviously collide) you
> > may still get bitten by something less obvious that collides with
> > something getpwnam calls. I don't really buy this argument, because the
> > obvious counter is to use a _universal_ mutex for _all_ non-thread-safe
> > stuff, then they can interact as much as they want, coz only one will be
> > running in practice. Stuff that uses this without APR's assistance in
> > Apache is just plain broken, and not to be worried about. IMO.
> 
> You are correct, this is just plain broken, but at what point are you sure
> that you have all of the functions covered in APR?  Unless you really
> investigate the C Run-time to find ALL of the interactions, there is a
> good chance you will miss one or two.

In which case you were screwed anyway, surely?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Mime
View raw message