Re: suenv

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Oct 23, 2012 at 10:46:53AM -0500, Eric Haszlakiewicz wrote:
> On Tue, Oct 23, 2012 at 11:12:55AM -0400, Thor Lancelot Simon wrote:
> > 
> > I advocate that this is eminently better than pretending security software
> > (that had trivially detectable buffer overruns) "worked" when in fact it
> > worked, if at all, only more often than not.
> > 
> > If those two modules have bugs, the bugs should be fixed.  Breaking
> > NetBSD to accomodate those modules' bugs is not an option! 
> 
> Is it a bug to use pthreads?
> Having "trivially detectable buffer overruns" sounds like a completely
> different issue than not being able to load libpthread, or are they
> related somehow?

They're related: look where the buffer overrun is.

> How did those modules work pre-6.0?  I thought pthreads wouldn't work
> at all when loaded through dlopen because libc would have initialized 
> in non-threaded mode at process startup.

They may have appeared to work sometimes; even most of the time.
But code that uses threads, executing within a process which
was not linked against libpthread when it was built, cannot
actually work all the time (nor is it guaranteed to work at
all by the standard).  It is like writing a large threaded
program and leaving all the locking out of a few critical
sections: you might trick the customer into thinking the few
random failures and the consequent data corruption is his
fault, but of course it will really be your fault.

NetBSD 6 was fixed to loudly rather than silently fail in
such cases.  That was the right decision, rather tha
allowing application authors to silently hose applicatio
users.

This case is particularly ugly, since the result of
undefined application behavior can be a bad authentication
decision!  I submit that anyone who does not understand
that that was what could happen before, nor that the
various proposed solutios either heavily penalize
correct, non-threaded applications or simply don't work
in important cases has not actually looked at the details
of the problem hard enough.

There are cases where desperate, ugly hacks to make
other people's incorrect code work most of the time
are justifiable.  The system authentication path is
not one of them!