Re: Securing "make check" (CVE-2014-0067)

On Sun, Mar 02, 2014 at 11:36:41PM +0100, Magnus Hagander wrote:
> On Sun, Mar 2, 2014 at 7:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> > Noah Misch <noah@leadboat.com> writes:
> > > One option that would simplify things is to fix only non-Windows in the
> > back
> > > branches, via socket protection, and fix Windows in HEAD only.  We could
> > even
> > > do so by extending HAVE_UNIX_SOCKETS support to Windows through named
> > pipes.
> >
> > +1 for that solution, if it's not an unreasonable amount of work to add
> > named-pipe sockets in Windows.  That would offer a feature to Windows
> > users that they didn't have before, ie the ability to restrict connections
> > based on filesystem permissions; so it seems useful quite aside from any
> > "make check" considerations.
> >
> 
> I think it might be a bigger piece of work than we'd like - and IIRC that's
> one of the reasons we didn't do it from the start. Named pipes on windows
> do act as files on Windows, but they do *not* act as sockets. As in, they
> return HANDLEs, not SOCKETs, and you can't recv() and send() on them.

I have experimented with Windows named pipes.  PQsocket() creates thorny
problems on the client side.  That function is central to asynchronous use of
libpq, in which you call select(), poll() or similar on the returned socket.
To expand that to cover Windows named pipes, we might provide two new libpq
functions.  The first would return an opaque connection handle.  The second
would resemble select() or poll(), accept the opaque handles, and use relevant
OS primitives internally.  The need to make such a prominent user-visible
libpq change dims my affection for this strategy.  (Challenges on the server
side were simple matters of programming thus far.)  This is similar to the
problem PQgetssl() poses for new SSL implementations.

It then dawned on me that every Windows build of PostgreSQL already has a way
to limit connections to a particular OS user.  SSPI authentication is
essentially the Windows equivalent of peer authentication.  A brief trial
thereof looked promising.  Regression runs will need a pg_ident.conf listing
each role used in the regression tests.  That's not ideal, but the buildfarm
will quickly reveal any omissions.  Unless someone sees a problem here, I will
look at fleshing this out into a complete patch.  I bet it will even turn out
to be back-patchable.