Re: AF_UNIX status report

[Ken Brown <kbrown@cornell.edu>]

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.)

Ken