AF_UNIX status report
Ken Brown
kbrown@cornell.edu
Thu Dec 17 15:54:28 GMT 2020
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
More information about the Cygwin-developers
mailing list