Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp463628imm; Thu, 13 Sep 2018 02:43:21 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYZ0EbM0OjJD8fAOmcODdMiE7foYOexiT8g5g8T/bzu4rl2IwOtRg+h/xlcmGRckwUdmO1J X-Received: by 2002:a63:9c19:: with SMTP id f25-v6mr6415316pge.447.1536831801591; Thu, 13 Sep 2018 02:43:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536831801; cv=none; d=google.com; s=arc-20160816; b=mSYGFz7uzrS2glno4rlGDj6TxsHZta62bPlEvf670+XzjPECMtkN5S3jKdxKMD7u/B mpKl6dIoeB880m+7eH5XWwfgbCAm1H2jAHhcK271bdqpEZrOJtMS5I5RJfjIgNAvtdHo 4yIzwTtVhdrmcWVcvflPFA2SbUu9DSPGNTU/ahBBQ9D8iPpHkSniud9+t8qACwmYHVKC xzV2HuBbG/d7/YYwfkmlgbIPXp3jZZF3/myenA2uB/YnInkuvU7msyZSTL0Qj37YYq+S 8Y/wFp7xjHDjMAltvaeyMMn8dDjojc/3HqAkM3dQmvQxhxobY+bq3oCiN05NApDx6unJ A3LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=F0lX0q/2loeQwAwjB3Fbc59n+zY7gdpW64ZuyHP5j/A=; b=eeIiBsQdm/e+XW5fRnIMYpW4pD1tYQjviGYvmcisJRsKJaG/pSv1UsGANP4awr0iwM Gf5noiUVKgc8JhevIUiYbNzunJpwWm+ezRIc1AVnv77H3sIxSb0cVd0hcqWZTV7BE8s8 8Yr8KE/S0IA8EcJSbyyGPZehH4JyArMr9rY8atqc49kva3m6OGsYlfj1artgCE8yUaJ8 5/ixeyh0Kli31So7/54atc+jzsBb5ybrdM4TROXr8LNqebqCrm+m2f+sdtaKX3/BVWbx IHOMd6Lfp2vPSAbHSwonKDQoLIHSvueH9G3/UlchAUeQqIrSso9/AV7JGH67DrTdBor3 T+KA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w14-v6si3440120plp.183.2018.09.13.02.43.05; Thu, 13 Sep 2018 02:43:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727685AbeIMOuW (ORCPT + 99 others); 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--