AF_UNIX status report

[Ken Brown]

On 11/26/2020 12:06 PM, Ken Brown via Cygwin-developers wrote:
> On 11/23/2020 3:43 AM, Corinna Vinschen wrote:
>> On Nov 22 15:44, Ken Brown via Cygwin-developers wrote:
>>> On 11/18/2020 3:34 AM, Corinna Vinschen wrote:
>>>> On Nov 17 14:57, Ken Brown via Cygwin-developers wrote:
>>>>> On 11/9/2020 4:08 AM, Corinna Vinschen wrote:
>>>>>> The duplicated handle has to be closed at one point but otherwise
>>>>>> the approach makes sense.
>>>>>
>>>>> After wasting a ridiculous amount of time because of careless mistakes with
>>>>> handle duplication, I've finally gotten something working (currently for
>>>>> disk files only and with some limitations that have to removed).  I've
>>>>> pushed it to the topic/af_unix branch in case you want to review it and/or
>>>>> test it.
>>>>
>>>> This is soooo fantastic!  Apart from files, the nexst most interesting
>>>> case is sharing a socket, probably.  We could activcate the 2nd half of
>>>> privilege separation in sshd then.
>>>
>>> I've pushed a first attempt to implement sending socket descriptors, but I
>>> haven't yet tested it.  I'll try to find a small test program and then, if
>>> all goes well, take a look at sshd.
> 
> I've now tested it with a small program that forks a subprocess, accepts a 
> connection on an AF_INET socket, and sends the resulting socket descriptor to 
> the child, using an AF_UNIX socketpair for parent-child communication.  It seems 
> to work as expected.  The test is in winsup/cygwin/socket_tests on the 
> topic/af_unix branch, with a description of how to run it in README.txt.
> 
> I took a quick glance at the openssh code, and I think I see places where 
> pty/tty descriptors are sent.  For example, I see calls like mm_send_fd(sock, 
> s->ttyfd).  So maybe I need to try to add support for that next.  This could 
> take some time since I'm not familiar with the code for fhandler_termios or any 
> of its derived classes, nor do I have any idea how to test sending that kind of fd.

I've now written and tested code for sending pty slave descriptors.  This is the 
first case I've dealt with in which the fhandler uses an archetype, and I'm not 
completely sure that my approach is right (though I can't think of an alternative).

Suppose a process wants to send a pty slave descriptor for /dev/ptyN.  The 
receiving process checks whether it already has an archetype for that device. 
If so, it uses it.  If not, it creates a new one by duplicating handles from the 
sending process.

The first case (in which the receiving process already has an archetype) bothers 
me, because it means that deserialization uses no information about the fhandler 
it receives other than the device number.  That seems wrong, somehow, though I 
can't really say why.

If you want to see exactly what I've done, it's in commit c605ea0d on the 
topic/af_unix branch.

Ken