From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.pismotec.com (mail.pismotec.com [100.42.30.2]) by sourceware.org (Postfix) with ESMTPS id E23FD3857817 for ; Thu, 5 Nov 2020 19:54:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E23FD3857817 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=pismotec.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joe@pismotec.com Received: from [10.7.1.101] (50-39-143-95.bvtn.or.frontiernet.net [50.39.143.95]) by mail.pismotec.com (Postfix) with ESMTPSA id 569EF14BE0D9 for ; Thu, 5 Nov 2020 11:54:29 -0800 (PST) Subject: Re: AF_UNIX status report To: cygwin-developers@cygwin.com References: <1d0ea5dc-7e9b-d8fe-5f6e-da7a799a3b13@cornell.edu> <20201027094340.GJ5492@calimero.vinschen.de> <0f945b4c-aa30-e08e-9f86-d4b41279ba10@pismotec.com> <20201030092019.GW5492@calimero.vinschen.de> <38e33f7a-e87d-fea8-ac9e-826f94c189d4@cornell.edu> <20201104120304.GF33165@calimero.vinschen.de> <88b3dfe6-a67d-c597-afe2-4edb13cee5d7@cornell.edu> <20201105172140.GP33165@calimero.vinschen.de> <90fdecee-fb2d-6b24-ef30-356df2dbc3d2@cornell.edu> From: Joe Lowe Message-ID: <59856c67-d643-b662-bec5-69bbc6a81d19@pismotec.com> Date: Thu, 5 Nov 2020 11:54:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <90fdecee-fb2d-6b24-ef30-356df2dbc3d2@cornell.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * 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: Thu, 05 Nov 2020 19:54:32 -0000 On 2020-11-05 11:01, Ken Brown via Cygwin-developers wrote: > On 11/5/2020 12:21 PM, Corinna Vinschen wrote: >> On Nov  5 09:23, Ken Brown via Cygwin-developers wrote: >>> OK, here's how I imagine this working: >>> >>> A process wants to send a file descriptor fd, so it creates a msghdr >>> with an >>> SCM_RIGHTS cmsghdr and calls sendmsg.  The latter creates and sends >>> an admin >>> packet A containing the fhandler for fd, and then it sends the original >>> packet P. >>> >>> At the receiving end, recvmsg sees packet A first (recvmsg is always >>> checking for admin packets anyway whenever it's called).  It stores the >>> fhandler somewhere.  When it then reads packet P, it retrieves the >>> stored >>> fhandler, fiddles with it (duplicating handles, etc.), and creates >>> the new >>> file descriptor. >> >> Actually, this needs to be implemented in a source/dest-independent >> manner.  Only the server of the named pipe can impersonate the client. >> So the server side should do the job of duplicating the handles.  If the >> sever is also the source of SCM_RIGHTS, it should send the fhandler with >> already duplicated handles. > > Ah, OK.  I was thinking of it differently.  Rather than having the > server impersonate the client, I was thinking that the sender would send > its winpid as part of its admin packet, which the receiver could then > use to get a handle to the sender's process.  The receiver could then > duplicate the handles.  But maybe your approach is better.  I'll have to > rethink it. SCM_RIGHTS on *nix; fd are retained by message buffering in the kernel. A sending process can close an fd after sendmsg is called, before recvmsg is called in the receiving process. SCM_RIGHTS on *nix; fd are not added to a receiving process fd table until the SCM_RIGHTS message is read. This is a consideration for DOS attacks. So I expect it is necessary to create a temp copy of each fd being sent, so the sender can close the original. And I expect it is necessary to use handshake/acks between the two processes; so the DuplicateHandle() call can happen in the correct process and not until the SCM_RIGHTS message is read. >>> Does this seem reasonable?  The main thing bothering me is the lack of >>> atomicity.  I don't like the gap between the sending of the two >>> packets A >>> and P, and similarly for the receiving.  I thought about using the >>> io_lock >>> to at least make sure that the two packets are adjacent in the pipe, >>> but I >>> don't know if we want to tie up the io_lock for that long. >>> >>> Also, the sending process might be sending several file descriptors >>> at once, >>> so that there would be several admin packets to be sent (unless we >>> want to >>> cram it all into one). >> >> We can safely assume that pipe packets up to 64K are sent and received >> atomically. >> >> In most cases this shouldn't be much of a problem.  Most scenarios using >> SCM_RIGHTS send no or only a minor payload.  Most scenarios share a >> single or only a handful of descriptors. >> >> Apart from that, Linux also defines SCM_MAX_FD, the max. number of >> descriptors in a single sendmsg call.  If the number of descriptors >> is larger, sendmsg returns EINVAL.  SCM_MAX_FD is 253 on Linux, but >> >> What that means to us is, we can choose our own SCM_MAX_FD and just >> return EINVAL if the number of descriptors is uncomfortably high. >> The max. number of descriptors should be limited so that all descriptors >> fit into 64K, or even 32K, just to leave space for payload. >> Assuming a size of about 600 bytes per fhandler, 50 might be a good >> candidate for SCM_MAX_FD.  I'd say even 32 would be sufficent for most >> scenarios. >> >> The idea would be to create the packet on the source side with all >> fhandlers in the ancilliary data block, followed by the payload. >> This should typically fit in a 64K package.  If not, only the >> payload needs to be split into multiple packages.  Do we really >> need atomicity there?  Not sure, but only then we'd need an io_lock. Joe L.