On Wed, May 30, 2018 at 09:59:01AM +0800, Craig Ringer wrote:
> On 30 May 2018 at 09:53, Andres Freund <andres@anarazel.de> wrote:
> > On May 29, 2018 9:44:09 PM EDT, Craig Ringer <craig@2ndquadrant.com> wrote:
> > >https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/
> > >
> > >The latest Windows 10 update shipped with AF_UNIX socket support for
> > >win32
> > >sockets.
> > >
> > >It's not that exciting because it doesn't support socketpair() or fd
> > >passing - yet. So really it doesn't offer us much more than we can
> > >already
> > >get with win32 named pipes. We can - and do - already get fd passing
> > >with
> > >DuplicateHandle anyway.
> > >
> > >Still, I thought it was interesting. We could probably just
> > >conditionally
> > >enable AF_UNIX sockets on new enough windows SDKs. Apparently if it's
> > >not
> > >supported by the OS runtime you get a graceful error.
> >
> > Last time I checked it didn't support transporting user identification
> > though. Which means not that much value would be added. Is that still the
> > case?
>
> Right, so it is. I missed that.
>
> They implemented unix sockets, except the interesting bits.
For use as a frontend/backend protocol transport, these are the interesting
bits:
1. User identification for peer auth
2. Enforcement of file modes from socket's ancestor directories
3. Compatibility with select() and other socket APIs
The article says the implementation has (2), and (3) seems likely. For (1),
Windows already supports user identification over TCP, which PostgreSQL uses
to implement SSPI authentication. I expect that to work equally well over
AF_UNIX, and adding a getpeereid() equivalent would not help much.
While enabling AF_UNIX sockets on Windows wouldn't achieve anything wondrous,
it would unblock check-world testing src/test/authentication on Windows.
