Cygwin AF_UNIX emulation

Corinna Vinschen
Sat Oct 18 10:35:00 GMT 2014

On Oct 17 21:29, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Oct 16 23:34, Christian Franke wrote:
> >>Nasty detail: At least postfix sets the all AF_UNIX sockets to rw-rw-rw- and
> >>relies only on directory permissions (private: rwx------, public: rwx--x---)
> >>for access control. This is not effective on Cygwin. Due to the rw-rw-rw-,
> >>the 'secret' is world readable on Cygwin and another Cygwin specific patch
> >>is required :-)
> >Yeah, thanks to Windows which enables the "Bypass Traverse checking"
> >privilege for everyone :(  At one point in 2005 I toyed with traverse
> >checking but eventually gave up in 2006 and reverted the stuff.
> This does not appear as an Se*Privilege in the token, correct?

It's in the token, and it's an ugly amalgamation of two unrelated


    Required to receive notifications of changes to files or
    directories. This privilege also causes the system to skip all
    traversal access checks. It is enabled by default for all users.

    User Right: Bypass traverse checking.

> Any idea why this was added for everyone?

It's in there and set by default since the dawn of (NT) time, probably
for the notifications to work, and as a side-effect, being faster.

> >In theory, a malicious server could wait for the client package and
> >read the content, thus it knows the socket secret and send its own
> >package with the secret gained from the client.
> That's exactly why the server bind() should write two independent secrets to
> the file. Receiving the secret from the client does not help the attacker to
> fake the server secret then.
> The only drawback which remains is that the client performs the send()
> before first recv() unconditionally. It will realize the bad server secret
> lately on first recv().

Yeah, but it might be better than nothing and if it avoids the hangs,
even better.

> >Btw., considering my change to call the connect side of the handshake
> >only when an FD_CONNECT arrives, what exactly is postfix still missing?
> >[...]
> With 20141014 snapshot, it hangs in poll({client_sd, POLLOUT}, 1, -1) after
> a nonblocking connect() and could not be kill()ed.
> postfix master unconditionally starts up some services like qmgr and pickup
> by connecting to itself:
>   bind(listen_sd, "public/pickup")
>     listen(listen_sd, .);
>             set_nonblocking(client_sd);
>             // Cygwin 1.7.32-1 hangs here:
>             connect(client_sd, "public/pickup");
>             // Snapshot 20141014 hangs here:
>             poll({client_sd, POLLOUT}, 1, -1)

Oh, ok.  The FD_CONNECT handling just moved the hanging to a later
call to wait_for_events.  Sigh.

> BTW: I could ITP postfix in one week or so. It would rely on the SO_PEERCRED
> workaround for now. Any objections?

Uh, we're not having a Cygwin release it could work with for now.
It might be better to wait until then, if that's ok with you.

I'm planning to release 1.7.33(**) in November at the latest.  I'm
not going to stall this release until we have another solution for
the aforementioned problems, the SO_PEERCRED wourkaround should
suffice for now.

> >Independently of that, I'm mulling over the idea to introduce a
> >sidechannel via pipe.
> Hmm... sounds promising.

...and like a lot of work.  Any other, simpler idea welcome.

Btw., I'm also just looking into the WSAAccept and WSAConnect functions.
These functions provide a way to submit application controlled connect
data in a handshake-like operation, and they are supposed to work with
non-blocking sockets.  Maybe these functions would work for us?

Also, starting with Windows Vista there is a function
WSAImpersonateSocketPeer.  Yes, really.  Maybe that's a way out, which
would also leave Windows XP/2003 behind.  Given that XP is out of
support now, and given that 2K3 goes out of support next April, I'd
not be overly concerned.



(**) Or 1.9.0.  I'm not sure yet if we should bump the DLL major version
     due to the massive changes to user and group handling or not.

Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Cygwin-developers mailing list