From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) by sourceware.org (Postfix) with ESMTPS id 2385A386F47E for ; Wed, 16 Dec 2020 09:29:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2385A386F47E Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MsJXG-1jwp4P3TUg-00tl6x for ; Wed, 16 Dec 2020 10:29:27 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 5AB7EA82BD8; Wed, 16 Dec 2020 10:29:27 +0100 (CET) Date: Wed, 16 Dec 2020 10:29:27 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: AF_UNIX status report Message-ID: <20201216092927.GE4560@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <20201106091240.GT33165@calimero.vinschen.de> <99e02f87-1c58-ce6f-58e0-0deb26c4c899@cornell.edu> <20201109090812.GV33165@calimero.vinschen.de> <6c3e9c53-8575-de80-be2d-49af2b87eaa5@cornell.edu> <20201118083447.GL41926@calimero.vinschen.de> <20201123084313.GK303847@calimero.vinschen.de> <84f2fc71-a1bb-0496-93dc-ef21c46fd432@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Provags-ID: V03:K1:YfrtRbSRKFNWG4aG8rDC5Fn0Y7O9goRA5NcIdjo9CzXUDxkGaet hfvQSamb9zC5dhCVvO3EI1IcxTVeeQOTtVvWC2igf35+p4Fnp/RqtnDcreqSkx5Udw/7B5Y 0oGBcx9PUVVq7+YB3b/40u84LRWqPBf7M/381hyyIPIL14lORc/2r2UAjUfKTlv+qcaa7Sj u+lQysNwxwj1GDY7/32kw== X-UI-Out-Filterresults: notjunk:1;V03:K0:mDBd1qvFTbs=:Yl9Ln41Ht9HysbdynXvz1E /zIfS7780wrU9Erb+mPqgGru0oPClk8zumWPVr7ceG4vhZKNjRz9hbGZoOZO4Hz9rEN+rgj8S CM2AMLVRnM9h805Zl9SLUuTVjPwDjKog2myBJORVx4TdYyEDz2cNWqYPlb+uJJBZUoN49Evit XFEloUx6jE9osclLkMNTTq9+nIMLhUY7cSHtqK3KpfA1gs4rFusxmURVPGUUCdYywj2+g1Q2x KOIpLNno7mGY7vsRAfjLNXfEzbFq8RukX+4IJ7fQ3aLRaLU95HeRVTUbrqlboqjgOR191SQc2 +sd/p7TB8QdKTn1YNg/LonqX4Ea0SkA5Uw7RSdcQEbXZUXjD+ucs2mAYx43t/UeXvpikAQGYV lMoENmK5/6gTyWy/7PKaUMqhUc38gVgCvJxC+AN8dZM7F0F19+zRDFfeakvHzgTgfgNPEVy/g 1/DZuYpH+w== X-Spam-Status: No, score=-100.7 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, JMQ_SPF_NEUTRAL, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 09:29:30 -0000 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