From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07E97C04ABB for ; Thu, 13 Sep 2018 09:41:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A523020881 for ; Thu, 13 Sep 2018 09:41:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A523020881 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727752AbeIMOuW (ORCPT ); Thu, 13 Sep 2018 10:50:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:57918 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726741AbeIMOuW (ORCPT ); Thu, 13 Sep 2018 10:50:22 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 027D6ACE5; Thu, 13 Sep 2018 09:41:38 +0000 (UTC) Date: Thu, 13 Sep 2018 19:42:56 +1000 From: Aleksa Sarai To: Andy Lutomirski Cc: Tycho Andersen , Kees Cook , Jann Horn , Linux API , Linux Containers , Akihiro Suda , Oleg Nesterov , LKML , "Eric W . Biederman" , Christian Brauner Subject: Re: [PATCH v6 4/5] seccomp: add support for passing fds via USER_NOTIF Message-ID: <20180913094256.gpwrlu4gnjn6zyhn@mikami> References: <20180906152859.7810-1-tycho@tycho.ws> <20180906152859.7810-5-tycho@tycho.ws> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6ksm43o3rqx7ajcf" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --6ksm43o3rqx7ajcf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2018-09-12, Andy Lutomirski wrote: > > The idea here is that the userspace handler should be able to pass an fd > > back to the trapped task, for example so it can be returned from socket= (). > > > > I've proposed one API here, but I'm open to other options. In particula= r, > > this only lets you return an fd from a syscall, which may not be enough= in > > all cases. For example, if an fd is written to an output parameter inst= ead > > of returned, the current API can't handle this. Another case is that > > netlink takes as input fds sometimes (IFLA_NET_NS_FD, e.g.). If netlink > > ever decides to install an fd and output it, we wouldn't be able to han= dle > > this either. >=20 > An alternative could be to have an API (an ioctl on the listener, > perhaps) that just copies an fd into the tracee. There would be the > obvious set of options: do we replace an existing fd or allocate a new > one, and is it CLOEXEC. Then the tracer could add an fd and then > return it just like it's a regular number. >=20 > I feel like this would be more flexible and conceptually simpler, but > maybe a little slower for the common cases. What do you think? When we first discussed this I sent a (probably somewhat broken) patch for "dup4" which would let you inject a file descriptor into a different process -- I still think that having a method for injecting a file descriptor without needing ptrace (and SCM_RIGHTS) shenanigans would be generally useful. (With "dup4" you have a more obvious API for flags and whether you allocate a new fd or use a specific one.) --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --6ksm43o3rqx7ajcf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEXzbGxhtUYBJKdfWmnhiqJn3bjbQFAluaMR0ACgkQnhiqJn3b jbRdog//SGIbgcHJBzJCVik/HjW9K8MCFuwaWPTMH5NvZ3L7mVM8z3sztN91sA3R FMK/t0DfXk7sTQaBo8hy4J636GR37f+GSt1AqowHLiBjOD3zagA6/DO6/9SH7cER 8UsA4sWbdy8s1yEKuOs4q8YMqwvOlSBJGRS/9s4T7I2PaGSHFVxzHWpRnEaQKjHe fLBDQOAyBu1qGkv5KS1W0uXenjX1cybkYlnZjrsfzd7D7lwcsjKpeZJanrKReS5a ehHqpiDkI2/IqokIEOqK23SoctJlOFgAVuL5tY7KH7VlC0Vqp+1P5iOD1PEdLzWu ZHN3TN9U5jmOiUaJebWoylvq06IdllFaiaaRDzBw7HXSUsrJKISHXH04p5Zb8mkC x0dkuuf+w3fD2/PYHSFxW+QyywuI25+cUHEYUqSqAnJy7gBJDHCv3zp5T1Ab/nHf SkcHkJxOUCiR3G2ncZMnF2vaYdqVS1rvPPeAkjxVeUVyCkR2G9pkxqeMJMCv5NRR HaXtS0eN5+tva84gSJy5Q8iq9opYVri/6avLvlyQCuNPt/YSBeTOSiZYeamDIxjY DZiBI/mv2vDOQUoAY3TpDkhchXq7Tif3B+DED4n3AtduAxojti+tG+pdMMFuCO7g gpYDbd/qbTCb3NSlqIxw1pzMXJsPUx3eCOJH69mJUf6QB0Bd5I8= =EVfp -----END PGP SIGNATURE----- --6ksm43o3rqx7ajcf--