From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) by sourceware.org (Postfix) with ESMTPS id 5FDEA3958C08 for ; Mon, 19 Apr 2021 08:48:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 5FDEA3958C08 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=cygwin.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=corinna-cygwin@cygwin.com Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MsZeX-1lo9uu3LMx-00u3bK for ; Mon, 19 Apr 2021 10:48:39 +0200 Received: by calimero.vinschen.de (Postfix, from userid 500) id 1D2EBA80EC7; Mon, 19 Apr 2021 10:48:39 +0200 (CEST) Date: Mon, 19 Apr 2021 10:48:39 +0200 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: Problems with the (new) implementation of AF_UNIX datagram sockets Message-ID: Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <1cfa2d74-eaa4-e3be-9fa5-519952026aef@cornell.edu> <9db1d7ab-fe47-6f8c-db65-c9fe5e18952b@maxrnd.com> <8cec7dd0-5a0a-1e38-66d0-3c92854d1a69@maxrnd.com> <27dadaaf-68d5-a529-2c87-9a08ef1f86df@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <27dadaaf-68d5-a529-2c87-9a08ef1f86df@cornell.edu> X-Provags-ID: V03:K1:2KleulIxyEcZpohJy7ft0baYR22ZXpOr6OTONiB80cc4shz/duh p6gTfVUsCi2Lw4X25B16bSUMxzVk03vpN6BcWh9guaZxIqYv4vGTeiritJ741hAjlzycDH3 KvJisf2dfS+8AnD0P4t7RHBKoh/ZdRo3tz5beaSvff7YW6+HpNeWlgocnN+IMWtheDRrtQU Er7D4gAjk5cfmpWy0OQ3g== X-UI-Out-Filterresults: notjunk:1;V03:K0:6buSyPYspRA=:aktHbntAcTo6k3kP5QNDVQ 7CZHLGoKE5vYUoSNVzfEHRFENPUYy7DxtOStYgCUm8syXuL/jZZNe7r3VDzCNW9eJYDMudzeH ABlJoYwAm4I+mAzKsXjwptJdN6Yf6PX7dKXbf3oQVz+b/AB9ba8nDVup3z9hgD4mZIr50OVCZ M1dORrZdrCA+Ej2IGlBmqEyaaCeDpQrotoCmZcxgcT8P4judzGacANOckq03FBb9fQ+VDfSFD WQqYoGjYtG5rSVMvCdamKOxg1DskDBYx1EL4XPd2pzHuwP6QbVAOOKj4ivVpF+KxRfHG/nNbx R86Sw/Eoln1FU4E4MEn967P5hXEUrCGwVbxyMF5+LI8RoK80ADW7w85PKl5UqyMZqT7jMb/za 6idmD6t956FHKq7kZOqCG64k1IhGlOBgi5ihMtGpGe2DZWIovy+hWSQU3hder9Q9nXYZeSSqb ZMqSH7J756L2ZnTV6+xYCQRVMF366YTcUsWbhpA2MgbVttz9GNfXiT4O0vfVURJFiYhKdbHhs m5YG0HzPxNGvqmLVfFbr00= X-Spam-Status: No, score=-100.6 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Mon, 19 Apr 2021 08:48:52 -0000 On Apr 17 12:05, Ken Brown wrote: > On 4/16/2021 10:54 PM, Mark Geisert wrote: > > Corinna Vinschen wrote: > > > On Apr 15 16:50, Mark Geisert wrote: > > > > Sending datagrams between processes on the same system could be thought of > > > > as similar to sending/receiving messages on a POSIX message queue.  Though > > > > the mq_* man pages make it seem like mqs are intended for within-process > > > > messaging.  But if a datagram receiver created a message queue that datagram > > > > senders could open, couldn't that provide buffering and allow multiple > > > > clients?  Kindly ignore if insane. > > > > > > Interesting idea, actually.  Message queues already implement a lot of > > > what a unix socket needs in terms of sending/receiving data.  The pipe > > > would only be needed for credential and descriptor passing, ultimately :) > > > > One might be able to deal with credentials/descriptor passing within the > > message queue by using message priority to distinguish the "message" > > types. mq_receive() always gives you the oldest, highest priority, > > message available in the queue. > > > > I'll have to look over the usual DGRAM references again, but OTTOMH if > > credentials are just euids and egids maybe they could be handled as > > permissions on the file backing the message queue.  If the filename (in > > a particular name space we set up) is just the port number one could > > treat ENOENT as meaning nobody listening on that port, while EPERM could > > result from credentials not matching the file's permissions.  Makes some > > sense but I'm unsure if it covers all needs. > > A couple of comments: > > First, I don't think we want to limit this to DGRAM sockets. The code in > fhandler_socket_unix.cc already packages I/O into packets (see > af_unix_pkt_hdr_t), for both the STREAM and DGRAM cases. We could just > treat each packet as a message. In the STREAM case we would have to deal > with the case of a partial read, but I think I see how to do that. > > Second, I don't think we need to invent a new way of handling credentials. > We already have send_sock_info and recv_peer_info. The only question is > whether we use a pipe or a message queue. Corinna, what was your reason for > saying we need the pipe for that. Are there security issues with using a > message queue? Long-standing problem. The peer sends uid/gid values, but how's the server to know that these values are correct? The idea was to replace this at one point by a server-side call to ImpersonateNamedPipeClient and to retrieve the credentials of the peer in the server, so we actually *know* whom we're talking with. Corinna