From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2094.outbound.protection.outlook.com [40.107.100.94]) by sourceware.org (Postfix) with ESMTPS id 52DB33858001 for ; Sun, 8 Nov 2020 22:41:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 52DB33858001 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TlV1TjAjITTFOwGBuWvMgbiMH5qnpP4pIvQfRCmGntxRo0HiYGEp9d3I15y4KzhmyFmDve+RsnDxLfyVVFsLh2bZJp+tUGMQnBbSyuEN9CJaMO7nhHr8U6JdSA3uWQUKMw5lIpG/YbFP8E+bAzlsDYf/jnPhfUkvQK6AC6X60pnKrPDNb/7NBwf4PWX4AF33vYhsGTouHDErFIqUTH3T9XB3/vV0JAWZQ2UKJVfX0THSeCniO09Oy18uYRxgZmp7gJIs1wfBljYpiocbUsNUFGZkR1noQcBnD1njAyT8I0uaV5Lwjae+kp5hrhMxBjJkyJ+NQUWPOq/dIbgOt0/n/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rysDVLR6Nn/SRmCVtOM8mau6YDbe5LbLom/6WoRkG8I=; b=IcwQz/XHaR6ZH5iKjfvZR2Pvv9LBOtaQoBTt0rBFoOkyPDs/CaKy7bC1V/2+6TgebCe+JrIgNws9e+QEHUk/VbRJK2Ljpq8PRESXdVdw59X8XowGoFeWqhYke+GatVcHu6HmZoLPV0s8Cy/atj7Rn4e56I0C+w83Znv/AXVm+R+nVyCKE7S46RvYQBQ8CRwiXS79fp5tCadi7aW4Q4A33OGMuHWvY3bbSwlQ4RsJ6cIyCMYtsGKtlcr0mIrKYtmL2hZvdmF/3211MzdkFq+qpChnfs1+duGEDhGyALER9Mvee7ZWhyqVgDAE37SKUfsrQLVnzeyxrbiLwaiVGoNvDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cornell.edu; dmarc=pass action=none header.from=cornell.edu; dkim=pass header.d=cornell.edu; arc=none Received: from MN2PR04MB6176.namprd04.prod.outlook.com (2603:10b6:208:e3::13) by MN2PR04MB5599.namprd04.prod.outlook.com (2603:10b6:208:fe::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Sun, 8 Nov 2020 22:41:02 +0000 Received: from MN2PR04MB6176.namprd04.prod.outlook.com ([fe80::113e:c874:1207:eca8]) by MN2PR04MB6176.namprd04.prod.outlook.com ([fe80::113e:c874:1207:eca8%6]) with mapi id 15.20.3541.024; Sun, 8 Nov 2020 22:41:01 +0000 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> <80cb96b8-065d-b146-b879-170031ba28b5@cornell.edu> <20201106091240.GT33165@calimero.vinschen.de> From: Ken Brown Message-ID: <99e02f87-1c58-ce6f-58e0-0deb26c4c899@cornell.edu> Date: Sun, 8 Nov 2020 17:40:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [68.175.129.7] X-ClientProxiedBy: MN2PR07CA0021.namprd07.prod.outlook.com (2603:10b6:208:1a0::31) To MN2PR04MB6176.namprd04.prod.outlook.com (2603:10b6:208:e3::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.17] (68.175.129.7) by MN2PR07CA0021.namprd07.prod.outlook.com (2603:10b6:208:1a0::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Sun, 8 Nov 2020 22:41:01 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 86573dc8-5e33-47c5-8b76-08d884375e59 X-MS-TrafficTypeDiagnostic: MN2PR04MB5599: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: UMyPOQ+nC6+h3/BrLeer1nC/Rm0vivGEnVJumGbPeUndfZGjIpFzyWOgvjXezStMNcrqATVi6VbsK6p8ZVdD2Ym8HsweUb3ypplfQ2gLV0Y+MQ5kDF+prgpqUeEcwee8Z3cLD1Gm8legNw1ejMUDkpXX3goziuHwiWol2eqZS+eJl0On525uOsKr+vXVxvrRtQp3ix84S2/hW7rwgV/vM2SrPYP5w0u2sT5/00LoU7tCKsXwWErNfLNV7pnovM9Jso0DXxJSOfQ7a5L4R6BrqhQZbHmt2ey1pPx1JJfMad7/d7OCEwvcC8nRK1N+dJ9XWJa/+n27FJ6dRwBZhHir+8cxnldYJNsLWWDM2UFOCQQERoCatw9gSZkBkzuwUweD X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR04MB6176.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(136003)(39860400002)(396003)(376002)(66946007)(66476007)(66556008)(53546011)(8936002)(31686004)(75432002)(6916009)(86362001)(7116003)(2616005)(83380400001)(52116002)(956004)(6666004)(36756003)(186003)(6486002)(2906002)(478600001)(5660300002)(16526019)(316002)(786003)(16576012)(8676002)(26005)(31696002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: 3FmMY9iDx2Fl2wurd12tQoN/ipd/o0sRGndLTb+5QtdAG+ihVdsmr+yx1MjxwTrSC2lhSzDZEk2LIMP564YYj4ycbucalU3p0ZqgGJrDIyra+U5vkdOMufz7kImBnWTM4+k9PGDi1WAabzq+Ag6dpJGZAoKvytNQ2ZZ0K3uxA6c3pqiwtcm699zMSkgA5GIT1/qs5WXpIxtRruxOxSswFewmqJZw4Ge3zpe3vx/Ftgx8Eti2+PHjkMndpBfhG0WimDLgiduquFXEfdWqq5WG7zPbXabw33fFKSQDqmdPKqUNL0g2ioWH6Uu7G+g/x/Hv+yKjRY5drqo0M6xLJR9Kr2nGQVAtpIjeLzj2dj4jNdDRvL7E8cGq3+EWJbHC3T0IdCAZQ3CCPZMZsK/93AP9sWAm8mcdfQNBMzrdZRhmThtfKQoeDjrmQjjZgY7D3Fi+VRQUy0jItFOc6XzdOjXgIy0NakjsfytZcxRNNhIB1I4xCQLxBKSVo7G8LyGhyMVT8QridSUirdmgCn4sgmt8jO/ZWU7XIoOoAMRinCRQcDnLeWlbCaMvigOpwg1pvXIQzKzvDu8TNf7UE2FtLKTQER7RvMuC5Emq68qG33WuHzj0+li5OHQMmm+GpvgbYEw9oY67PGxM0eu9+3+hrpAfug== X-OriginatorOrg: cornell.edu X-MS-Exchange-CrossTenant-Network-Message-Id: 86573dc8-5e33-47c5-8b76-08d884375e59 X-MS-Exchange-CrossTenant-AuthSource: MN2PR04MB6176.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Nov 2020 22:41:01.7867 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0SkX78kZi9rlmknPOqrqOMpBQuaDHZSWLkXtUvxFbeTNDxp9HOlWe4VI8K+8GVZiAQKr/dfEit8x2o+qM4QWCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR04MB5599 X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, KAM_DMARC_STATUS, MSGID_FROM_MTA_HEADER, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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: Sun, 08 Nov 2020 22:41:05 -0000 On 11/7/2020 5:25 PM, Ken Brown via Cygwin-developers wrote: > On 11/6/2020 4:12 AM, Corinna Vinschen wrote: >> On Nov  5 18:41, 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. >>> >>> The only example of pipe client impersonation I can find in the Cygwin code >>> is in fhandler_pty_master::pty_master_thread.  Is this a good model to >>> follow?  If not, can you point me to other examples somewhere? >>> >>> AFAICT, the only reason for the impersonation is to check that the client >>> has appropriate permissions before trying to duplicate handles from the >>> server process to the client process.  Is that right?  What would go wrong >>> if we didn't check this?  Is the issue that the client process would have >>> handles that it can't access? >> >> 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.  [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. 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? Ken