[PATCH] Cygwin: allow opening an AF_LOCAL/AF_UNIX socket with O_PATH

[Ken Brown]

On 1/20/2020 4:35 AM, Corinna Vinschen wrote:
> On Jan 19 20:25, Ken Brown wrote:
>> On 1/17/2020 4:51 AM, Corinna Vinschen wrote:
>>> On Jan 17 10:48, Corinna Vinschen wrote:
>>>> On Jan 16 18:34, Ken Brown wrote:
>>>>> If that flag is not set, or if an attempt is made to open a different
>>>>> type of socket, the errno is now EOPNOTSUPP instead of ENXIO.  This is
>>>>> consistent with POSIX, starting with the 2016 edition.  Earlier
>>>>> editions were silent on this issue.
>>>>> ---
>>>>>    winsup/cygwin/fhandler.h               |  2 ++
>>>>>    winsup/cygwin/fhandler_socket.cc       |  2 +-
>>>>>    winsup/cygwin/fhandler_socket_local.cc | 16 ++++++++++++++++
>>>>>    winsup/cygwin/fhandler_socket_unix.cc  | 16 ++++++++++++++++
>>>>>    winsup/cygwin/release/3.1.3            |  7 +++++++
>>>>>    winsup/doc/new-features.xml            |  6 ++++++
>>>>>    6 files changed, 48 insertions(+), 1 deletion(-)
>>>>
>>>> I'm a bit concerned here that some function calls might succeed
>>>> accidentally or even crash, given that the original socket code doesn't
>>>> cope with the nohandle flag.  Did you perform some basic testing?
>>>
>>> Iow, do the usual socket calls on a fhandler_socket_local return EBADF
>>> now?  Ignoring fhandler_socket_unix for now.
>>
>> I really hadn't thought this through very well.  I think the following
>> additional patch should do the job:
>>
>> --- a/winsup/cygwin/net.cc
>> +++ b/winsup/cygwin/net.cc
>> @@ -67,6 +67,11 @@ get (const int fd)
>>
>>      if (!fh)
>>        set_errno (ENOTSOCK);
>> +  else if (fh->get_flags () & O_PATH)
>> +    {
>> +      set_errno (EBADF);
>> +      fh = NULL;
>> +    }
>>
>>      return fh;
>>    }
> 
> Looks like the easiest solution indeed.

It turns out that some further tweaks are needed, so it may be a while before a 
finish this.  And in the course of working on it, I discovered that I was 
careless when I attempted to support O_PATH for FIFOs in commit aa55d22c.  So 
I'll be sending a fix for that shortly, along with a test program, and then I'll 
return to the socket case.

I *think* what I did for symlinks is OK as it stands, but I'll recheck that too 
with a suitable test program.

Ken