Re: AF_UNIX status report

[Ken Brown <kbrown@cornell.edu>]

On 12/16/2020 4:09 PM, Ken Brown via Cygwin-developers wrote:
> On 12/16/2020 4:29 AM, Corinna Vinschen via Cygwin-developers wrote:
>> On Dec 15 12:33, Ken Brown via Cygwin-developers wrote:
>>> On 11/26/2020 12:06 PM, Ken Brown via Cygwin-developers wrote:
>>>> 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.
>>
>> I think it should be ok to use the archetype if it's available.  The
>> important tty data is shared.  The handles and stuff in the fhandler is
>> mostly connecting handles.  Permissions are not exactly taken into
>> account anyway.
>>
>> The connection to the pseudo console could be a problem, but reusing
>> the existing archetype may workaround that.  Otherwise the process
>> would be connected to two pseudo consoles, and I'm not sure that's ok.
>> I hope so, but...
> 
> I completely overlooked the pseudo console.  So I guess the 
> serialization/deserialization has to deal with get_ttyp()->h_pseudo_console 
> somehow.  My guess (based on only a very brief look at the pseudo console code) 
> is that this should be non-NULL only for the process that called 
> CreatePseudoConsole.  Does that sound right?  If so, then there shouldn't be 
> much to do.  I'll keep poking around, but please let me know if you see 
> something that I'm missing something.
> 
> (Takashi, if you happen to see this, please do the same.)

Answering my own question, yes, I was missing something.  I wasn't taking into 
account the fact that tty data is shared.  You said it, but it hadn't sunk in. 
I need to rethink this.

Ken