Re: vulnerability/SSL - Mailing list pgsql-general

From Marco Colombo
Subject Re: vulnerability/SSL
Date
Msg-id 1118328567.12004.192.camel@Frodo.esi
Whole thread Raw
In response to Re: vulnerability/SSL  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-general
On Thu, 2005-06-09 at 15:53 +0200, Magnus Hagander wrote:
[...]
> > > I guess we could read in the password ourselves and drop it in our
> > > shared memory segment to pass to subprocesses - though that
> > means they
> > > can get to the password easier as well. Assuming OpenSSL
> > has the APIs
> > > for that, I haven't checked that. I'm unconvinced it makes
> > enough of a
> > > difference to be worthwhile, though.
> > > (BTW, am I correct in reading this as a problem that only
> > appears on
> > > win32, because of the exec nature of the backend, right? Or does it
> > > show up on Unix as well?)
> >
> > Is the Unix version much different? I think the postmaster
> > just forks and execs the backends.
>
> It forks. It doesn't exec. As such, it inherits all the memory from the
> postmaster.

Oh, I need to check it out then. I thought the 'postmaster' executable
forks and execs 'postgres', and then they share mem via shmat(2). But
now I see they are the same executable - weird how I've never noticed
that before.

> > But, aren't connections
> > handled by the postmaster? All the SSL thing should happen
> > before the fork I think. Is the Windows model different? Do
> > backends handle SSL negotiation?
>
> On win32 we do fork() + exec(), and the OpenSSL library requires a new
> initialization, including reading the key. I should say I'm speaking
> from memory of stuff I looked at a longt ime ago, though - it could
> probably do with someone looking throuhg exactly how it is now ;-)
>
> IIRC, the problem is that the openssl structs contain function pointers,
> which are not guaranteed to point to the same thing in the child.

Ouch, I see the problem. You do need to pass the unencrypted key around
then, assuming openssl supports such a thing. Now I also see it's
useless to setup the openssl context only to destroy it with exec. So it
has to be the child to handle it.

.TM.
--
      ____/  ____/   /
     /      /       /                   Marco Colombo
    ___/  ___  /   /                  Technical Manager
   /          /   /                      ESI s.r.l.
 _____/ _____/  _/                      Colombo@ESI.it


pgsql-general by date:

Previous
From: "GIROIRE, Nicolas (COFRAMI)"
Date:
Subject: "returning" in postgresql request
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Strange transaction-id behaviour? (was Re: Two updates problem)