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 4AE313854825 for ; Thu, 29 Oct 2020 21:53:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4AE313854825 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 D8A5A14BE22A for ; Thu, 29 Oct 2020 14:53:34 -0700 (PDT) Subject: Re: AF_UNIX status report To: cygwin-developers@cygwin.com References: <1d0ea5dc-7e9b-d8fe-5f6e-da7a799a3b13@cornell.edu> <20201027094340.GJ5492@calimero.vinschen.de> From: Joe Lowe Message-ID: <0f945b4c-aa30-e08e-9f86-d4b41279ba10@pismotec.com> Date: Thu, 29 Oct 2020 14:53:33 -0700 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: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS autolearn=no 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: Thu, 29 Oct 2020 21:53:37 -0000 On 2020-10-29 13:19, Ken Brown via Cygwin-developers wrote: > On 10/27/2020 5:43 AM, Corinna Vinschen wrote: >> On Oct 26 18:04, Ken Brown via Cygwin-developers wrote: >>> I've made at least rudimentary implementations of all the >>> fhandler_socket_unix functions (including those in select.cc) for which >>> there were previously only placeholders. >>> >>> I've pushed everything to topic/af_unix, including a merge with >>> master as of >>> a couple days ago. >>> >>> I've cobbled together a few test programs and put them in >>> winsup/cygwin/socket_tests on the topic/af_unix branch.  I haven't >>> taken the >>> time to automate the tests, so they all have to be run >>> interactively.  There >>> is a Makefile to build the test programs and a README.txt that shows >>> how to >>> run them. >>> >>> One thing I haven't yet done is to think about (or systematically test) >>> datagram sockets.  I'm sure there's quite a bit of code that won't >>> work for >>> them. >>> >>> Aside from datagram sockets, there are still a few things that I'm >>> working >>> on, but I'm close to the point where I could use some input: >>> >>> 1. I've littered the code in fhandler_socket_unix.cc and select.cc with >>> FIXME comments on which I'd like advice. >> >> I'll look into it. >> >>> 2. I haven't given any thought at all as to how to implement SCM_RIGHTS >>> ancillary data.  I could definitely use suggestions on that before I >>> start >>> thrashing around. >> >> I have only vague ideas at that point.  Assuming we can replace the >> socket implemantation with the pipe implementation, what we have is a >> pipe which can impersonate the peer at least from the server side, and >> it knows the client process.  This in turn can be used to duplicate >> handles.  So what we could do is to define fhandler methods which create >> a matching serialization  and deserialization of the fhandler data, plus >> duplicating the handles for the other process, sent over the pipe as >> admin package.  This must work in either direction, regardless if the >> server or the client sends the SCM_RIGHTS block. > > This sounds reasonable. > > I have no experience with serialization.  Do you happen to know of a > good example that I could look at? > > Thanks. > > Ken I have experience building a secure implementation of SCM_RIGHTS type functionality over named pipe on Windows. This is not a small amount of code if you want to handle processes running as different users or privilege levels, and if you don't want to be a source of security vulnerabilities. You might consider building an implementation of SCM_RIGHTS that is only expected to work for processes running as the same user and privilege level. At least this would be a good starting point. This would cover the requirements of some unix code bases that use SCM_RIGHTS , and avoids significant security issues and complexity. Joe