Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp1326882ybs; Mon, 25 May 2020 13:03:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwnhJ6Enn9Xwd1Nj2upzSO0xSDXsO03KlfLILhVyP/8dd2Z5U04PqAN+dpTgFGE5QO+pTij X-Received: by 2002:a17:906:57d6:: with SMTP id u22mr19994884ejr.49.1590437014250; Mon, 25 May 2020 13:03:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590437014; cv=none; d=google.com; s=arc-20160816; b=BBeNarp56DfInKEw0kLPNElU83/KiLYJCglkZ5pXk+3UBTRo53FawrzACU3lTu0mcv 0zlb5J+NIRs72kx1sOjSc/8z0BiOrZQopJAftJcanDAKlmZw7Ilxa56kM+fcRmhdc3ky 4A1z7g3xaMtvO9iazFyNa6fu0L743OkoIJ4K0gmJ4u4WWIUUuoK38Bkpcc0btiJZJJoh zjzb+1D257mOk9O6uq81UqTadKE7Hxqvm3SFjbbPAoQoNz1cnOmDbBQAjWUm9+6Qk/K2 S98Y2ftuDjW4mgXNGytjaYOVTy53MZDSQEXVyxXQ7xpQVHOVQiLweNdBzP5PGb1zephx zwMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=dkQoRsMGoRx7eLNI+ElOCQ7kPe2HZlg7HXpAz5OFP0M=; b=a+Y9IrqCxkOQODz/bNP2EG/Rno7BtJZT/EjFVJQRXHBHGK1PklIgAFwrg/Il62o1y0 pKlGpHngMmltSiUUDBXmgLlxAOzjBEYMdAFgpLWYTtX0W9TMTgPctQ3MPP3DmqIQVdVp 8O/k2FEXp9SAG4fodZiR+SWk4a12IKDKEVTnSgeQ6tJ160eaOIYmr3IhzqXLsZiTjQHs WoP+bVViZ8F6VsTci6CNtxPOU5qAFE7E3a0InnwnIvp79QLpzua25X6KfOUnLPtldzjJ wbJbWPFDmwblkjheah9FB48FY+sWfP8JKqRNslbtEQKfngGmi7jX2eir/UdMcdjE28de cPkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n22si9800712ejr.497.2020.05.25.13.03.11; Mon, 25 May 2020 13:03:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390988AbgEYOUs (ORCPT + 99 others); Mon, 25 May 2020 10:20:48 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:38130 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388714AbgEYOUr (ORCPT ); Mon, 25 May 2020 10:20:47 -0400 Received: from ip5f5af183.dynamic.kabel-deutschland.de ([95.90.241.131] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jdDy9-0007LK-5u; Mon, 25 May 2020 14:20:45 +0000 Date: Mon, 25 May 2020 16:20:43 +0200 From: Christian Brauner To: Sargun Dhillon Cc: linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, linux-api@vger.kernel.org, tycho@tycho.ws, keescook@chromium.org, cyphar@cyphar.com, Jeffrey Vander Stoep , jannh@google.com, rsesek@google.com, palmer@google.com, Matt Denton , Kees Cook Subject: Re: [PATCH 4/5] seccomp: Add SECCOMP_ADDFD_FLAG_MOVE flag to add fd ioctl Message-ID: <20200525142043.jkdsfabntqusizxz@wittgenstein> References: <20200524233942.8702-1-sargun@sargun.me> <20200524233942.8702-5-sargun@sargun.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200524233942.8702-5-sargun@sargun.me> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 24, 2020 at 04:39:41PM -0700, Sargun Dhillon wrote: > Certain files, when moved to another process have metadata changed, such > as netprioidx, and classid. This is the default behaviour in sending > sockets with SCM_RIGHTS over unix sockets. Depending on the usecase, > this may or may not be desirable with the addfd ioctl. This allows > the user to opt-in. > > Signed-off-by: Sargun Dhillon > Suggested-by: Tycho Andersen > Cc: Matt Denton > Cc: Kees Cook , > Cc: Jann Horn , > Cc: Robert Sesek , > Cc: Chris Palmer > Cc: Christian Brauner > --- > include/uapi/linux/seccomp.h | 8 ++++++++ > kernel/seccomp.c | 31 +++++++++++++++++++++++++++---- > 2 files changed, 35 insertions(+), 4 deletions(-) > > diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h > index 7d450a9e4c29..ccd1c960372a 100644 > --- a/include/uapi/linux/seccomp.h > +++ b/include/uapi/linux/seccomp.h > @@ -115,6 +115,14 @@ struct seccomp_notif_resp { > > /* valid flags for seccomp_notif_addfd */ > #define SECCOMP_ADDFD_FLAG_SETFD (1UL << 0) /* Specify remote fd */ > +/* > + * Certain file descriptors are behave differently depending on the process "do behave"? > + * they are created in. Specifcally, sockets, and their interactions with the > + * net_cls and net_prio cgroup v1 controllers. This "moves" the file descriptor > + * so that it takes on the cgroup controller's configuration in the process > + * that the file descriptor is being added to. > + */ > +#define SECCOMP_ADDFD_FLAG_MOVE (1UL << 1) I'm not happy about the name because "moving" has much more to do with transferring ownership than what we are doing here. After a "move" the fd shouldn't be valid anymore. But that might just be my thinking. But why make this opt-in and not do it exactly like when you send around fds and make this mandatory?