AF_UNIX status report

[Corinna Vinschen]

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


Corinna