From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by sourceware.org (Postfix) with ESMTPS id 1E5EE385780E for ; Mon, 9 Nov 2020 09:08:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1E5EE385780E Authentication-Results: sourceware.org; dmarc=none (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 (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MiaLn-1k8m8w0YKt-00fkNg for ; Mon, 09 Nov 2020 10:08:13 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 20769A803FD; Mon, 9 Nov 2020 10:08:12 +0100 (CET) Date: Mon, 9 Nov 2020 10:08:12 +0100 From: Corinna Vinschen To: cygwin-developers@cygwin.com Subject: Re: AF_UNIX status report Message-ID: <20201109090812.GV33165@calimero.vinschen.de> Reply-To: cygwin-developers@cygwin.com Mail-Followup-To: cygwin-developers@cygwin.com References: <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> <80cb96b8-065d-b146-b879-170031ba28b5@cornell.edu> <20201106091240.GT33165@calimero.vinschen.de> <99e02f87-1c58-ce6f-58e0-0deb26c4c899@cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <99e02f87-1c58-ce6f-58e0-0deb26c4c899@cornell.edu> X-Provags-ID: V03:K1:fCMmaryr/SlzsdmEWlU6QrTfi986HjrbBN+U1gq+At8u2H1H3KE sWtpG/l32NFybHzarc9la4vMka2IQupFHSARBlIdyaHHmOjSeUJtPO7tdhqJyD/iyBMmTgH YMJjx/cw5ViY0HqkLBfn3kwTJZ+z6RWSb/TOKC8vS7aKCdaG9HUvobI3RWufp7hqNyn6hvM uMc2XtpdETaNIOwFpGpTA== X-UI-Out-Filterresults: notjunk:1;V03:K0:aNM1RTGaZL4=:QZ9pe17DoDtOS54RTQF9Xh QjdyDlzdUHdFB1+uuVhYOWAu9EzpsuKwvH/TAPO0oZGP9XxLN47UTbpY1/pDAet0OgKDyIils lP+T+d3qv+D/Ceo/cp4k8OUpmdu6smpYNK+FvXnA42zDwBW+sA+pZdIJYzYX/hR27PHUr4Sxt pLVcnovaRV56gYBVrY/EFzphVCaN0Ren45aGqOLY0PiCAsoFpaLkowh3VrvhnawuoJkr51u4s KDzi3i23tLuLLlGLBZXTVmTY8cE438KoAGDiOl+59rFiHVRxs25XcrM7+cWVYg/yT8Cd5rMEn UT+Ki8X57l5U/uvbzfB9jkB9lL51Yn8wS6DACHYDZCj7qRAXqiaId8U/2a41J5R9MV9mZ6XhS pHzKtlbT8YolFTtKbC/dprAwx8AET5+wUU13G2s6GieIYVJFizBTLsQVzhZ6MaBBldhBp/V2l TNMU/l900w== X-Spam-Status: No, score=-100.9 required=5.0 tests=BAYES_00, GOOD_FROM_CORINNA_CYGWIN, 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, 09 Nov 2020 09:08:16 -0000 On Nov 8 17:40, Ken Brown via Cygwin-developers wrote: > On 11/7/2020 5:25 PM, Ken Brown via Cygwin-developers wrote: > > On 11/6/2020 4:12 AM, Corinna Vinschen wrote: > > > Maybe I'm overthinking this.  A typical scenario for SCM_RIGHTS > > > involves a privileged and an unprivileged process.  The privileged > > > process sends an fd to the unprivileged process.  In this case the > > > sending process has admin rights anyway and can duplicate the handles > > > into the receiving process without having to impersonate. > > > > > > Either way, if both processes are running under the same user, or at > > > least one of the processes has admin rights, no impersonation is > > > required.  But since we don't know if the admin process is the sender or > > > the receiver, both sides must be capable of duplicating the handles. > > > > > > So, only if both processes are unprivileged, we would need to > > > impersonate.  This will almost always fail, unless both processes have > > > been started from (for instance) the same ssh session or one of the user > > > accounts has the SeImpersonatePrivilege privilege. > > > > > > Maybe we should just skip the latter scenario for a start. > > > > Good!  That way I don't have to get sidetracked learning about impersonation. > > > > Here's another issue involving serialization.  I'm not sure it's enough > > to just fiddle with the handles and then send the fhandler.  We also > > need to send the strings that are in the path_conv member of the > > fhandler. Hmm. Not in all cases, I think. For devices, major and minor numbers should be sufficient. Windows allows to regenerate the filename from the handle, too. For inet sockets there's no problem either. Paths under /proc and /registry are a problem, yeah. > > [I just noticed that you added path_conv > > serialization/deserialization recently, which should help with this.]  > > This increases the size of the data to the point where I think we need > > to send more than one packet when we're sending SCM_RIGHTS. > > > > Alternatively, instead of trying to send the fhandler and string(s) over > > the socket, we could store a copy of the fhandler, along with the > > serialized pc, in a named shared memory block.  The name could be > > something like "scm_rights...".  Then > > the sender would only have to send the device and inode, and the > > receiver could open the shared memory and reconstruct everything. device and inode are not sufficient. This may collide with other processes sharing an fd to the same file. The code should generate a unique identifier to name the shared mem and send this over the line. > Apart from this annoying issue of packets being too long, here's how I > imagine serialization/deserialization working. All the code below is > untested and probably full of errors, but I hope it gives the idea. Note: > get_size() below is the virtual method that I called size() in an earlier > message. > > struct fh_flat > { > fhandler_union fhu; > size_t name_len; > char data[0]; > }; > > /* Prerequisites: Modify fhandler_*::dup to take an optional winpid > argument specifying the process into which we want to duplicate > handles. Similarly modify dtable::dup_worker. */ > void * > serialize (int fd, DWORD winpid, size_t &len) > { > fh_flat *fhf; > size_t nlen = 0; > cygheap_fdget cfd (fd); > > if (cfd < 0) > { > set_errno (EBADF); > len = 0; > return NULL; > } > /* Make a copy of the fhandler with handles duplicated for winpid. */ > fhandler_base *copy = cygheap->fdtab->dup_worker (cfd, 0, winpid); > if (copy->get_name ()) > nlen = strlen (copy->get_name ()) + 1; > len = sizeof (fh_flat) + nlen; > fhf = (fh_flat *) cmalloc (HEAP_FHANDLER, len); > if (!fhf) > { > set_errno (ENOMEM); > len = 0; > return NULL; > } > memcpy (&fhf->fhu, copy, copy->get_size ()); > fhf->name_len = nlen; > if (nlen) > strcpy (fhf->data, copy->get_name ()); > return fhf; > } > > /* Return new fd, or -1 on error. */ > int > deserialize (void *bufp) > { > fh_flat *fhf = (fh_flat *) bufp; > cygheap_fdnew cfd; > > if (cfd < 0) > return -1; > /* Create an fhandler of the right derived class. */ > device dev = ((fhandler_base) fhf->fhu).dev (); > fhandler_base *fh = build_fh_dev (dev); > if (!fh) > { > debug_printf ("build_fh_dev failed"); > return -1; > } > memcpy (fh, &fhf->fhu, fh->get_size ()); > fh->set_name (fhf->data); > cfd = fh; > return cfd; > } > > Does this approach look OK? The duplicated handle has to be closed at one point but otherwise the approach makes sense. Corinna