On Sun, Mar 02, 2014 at 11:36:41PM +0100, Magnus Hagander wrote: > On Sun, Mar 2, 2014 at 7:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > Noah Misch <n...@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. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers