public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Michael McMahon <michael.x.mcmahon@oracle.com>
To: cygwin@cygwin.com
Subject: Problems with native Unix domain sockets on Win 10/2019
Date: Wed, 23 Sep 2020 12:25:51 +0100	[thread overview]
Message-ID: <2b0aeab4-983d-e1d7-301f-edfeeb38cc85@oracle.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

Hi,

I searched for related issues but haven't found anything.

I am having some trouble with Windows native Unix domain sockets
(a recent feature in Windows 10 and 2019 server) and Cygwin.
I think I possibly know the cause since I had to investigate a similar
looking issue on another platform built on Windows.

The problem is that cygwin commands don't seem to recognise native Unix
domain sockets correctly. For example, the socket "foo.sock" should
have the same ownership and similar permissions to other files
in the example below:

$ ls -lrt
total 2181303

-rw-r--r--  1 mimcmah      None             1259   Sep 23 10:22 test.c
-rwxr-xr-x  1 mimcmah      None             3680   Sep 23 10:22 test.obj
-rwxr-xr-x  1 mimcmah      None             121344 Sep 23 10:22 test.exe
-rw-r-----  1 Unknown+User Unknown+Group         0 Sep 23 10:23 foo.sock
-rw-r--r--  1 mimcmah      None             144356 Sep 23 10:27 check.ot

A bigger problem is that foo.sock can't be deleted with the cygwin "rm"
command.

$ rm -f foo.sock
rm: cannot remove 'foo.sock': Permission denied

$ chmod 777 foo.sock
chmod: changing permissions of 'foo.sock': Permission denied

$ cmd /c del foo.sock

But, native Windows commands are okay, as the third example shows.

I think the problem may relate to the way native Unix domain sockets are
implemented in Windows and the resulting special handling required.
They are implemented as NTFS reparse points and when opening them
with CreateFile, you need to specify the FILE_FLAG_OPEN_REPARSE_POINT
flag. Otherwise, you get an ERROR_CANT_ACCESS_FILE. There are other
complications unfortunately, which I'd be happy to discuss further.

But, to reproduce it, you can compile the attached code snippet
which creates foo.sock in the current directory. Obviously, this
only works on recent versions of Windows 10 and 2019 server.

All the best,
Michael McMahon


[-- Attachment #2: test.c --]
[-- Type: text/plain, Size: 1316 bytes --]

#define WIN32_LEAN_AND_MEAN

#include <windows.h>
#include <winsock2.h>
#include <WS2tcpip.h>
#include <stddef.h>
#include <stdio.h>
#include <afunix.h>

#define WIN32_LEAN_AND_MEAN


int __cdecl main(int argc, char *argv[])
{
    WSADATA wsadata;
    struct sockaddr_un addr;
    socklen_t len;
    int z = AF_UNIX;
    SOCKET s, s0;

    if (WSAStartup(MAKEWORD(2,2), &wsadata) != 0) {
        printf("STartup failed\n");
        return 0;
    }
    s0 = socket(AF_UNIX, SOCK_STREAM, 0);
    memset(&addr, 0, sizeof(addr));

    addr.sun_family = AF_UNIX;
    //strcpy(addr.sun_path, argv[1]);
    strcpy(addr.sun_path, "foo.sock");

    z = bind(s0, (const struct sockaddr *) &addr, strlen(addr.sun_path) + sizeof (addr.sun_family));
    if (z != 0) {
        printf("bind failed %ld\n", WSAGetLastError());
    }
    len = sizeof(addr);
    z = getsockname(s0, (struct sockaddr *)&addr, &len);
    if (z != 0) {
        printf("getsockname failed %ld\n", WSAGetLastError());
    } else {
        printf("getsockname works\n");
        printf("fam = %d, len = %d\n", addr.sun_family, len);
        int clen = len - offsetof(struct sockaddr_un, sun_path);
        printf("offsetof clen = %d\n", clen);
        printf("strlen = %zd\n", strlen(addr.sun_path));
        printf("name = %s\n", addr.sun_path);
    }
}


             reply	other threads:[~2020-09-23 11:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 11:25 Michael McMahon [this message]
2020-09-24 11:26 ` Ken Brown
2020-09-24 12:01   ` Michael McMahon
2020-09-24 17:11     ` Brian Inglis
2020-09-25 13:19     ` Ken Brown
2020-09-25 14:29       ` Michael McMahon
2020-09-25 14:37         ` Eliot Moss
2020-09-25 16:13           ` Michael McMahon
2020-09-25 16:32             ` Eliot Moss
2020-09-25 18:50         ` Ken Brown
2020-09-25 20:30           ` Ken Brown
2020-09-26  0:31             ` Duncan Roe
2020-09-26  1:22               ` Ken Brown
2020-09-26  7:30             ` Michael McMahon
2020-09-28 11:03               ` Michael McMahon
2021-01-30 16:00                 ` Ken Brown
2021-01-31 23:30                   ` Michael McMahon
2021-02-01 15:04                     ` Ken Brown
2021-02-01 15:10                       ` Corinna Vinschen
2021-02-07 19:35                         ` Michael McMahon
2021-02-08 15:30                           ` Ken Brown
2021-03-16 11:06                             ` Sv: " sten.kristian.ivarsson
2021-03-16 13:00                               ` Michael McMahon
2021-03-16 15:19                                 ` Ken Brown
2021-03-17 12:47                                   ` Sv: " sten.kristian.ivarsson
2021-03-17 15:47                                     ` Ken Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b0aeab4-983d-e1d7-301f-edfeeb38cc85@oracle.com \
    --to=michael.x.mcmahon@oracle.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).