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