Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp94439ybv;
        Tue, 18 Feb 2020 18:34:02 -0800 (PST)
X-Google-Smtp-Source: APXvYqzAEbTJ2K7yX1YK9bPMLcm3TAU3xBrvkHc5XCXcHSy5kp4i5JhWnhAh+tiIMAXL+3+PCXkJ
X-Received: by 2002:aca:ec46:: with SMTP id k67mr3135551oih.43.1582079641916;
        Tue, 18 Feb 2020 18:34:01 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1582079641; cv=none;
        d=google.com; s=arc-20160816;
        b=kiA5M8UdgqzF/XAN8Ux9Uqi++o200C88sOak2oPCsLyDSU2NKxuFvrUDm99JUPPsoW
         1dEOGRH0c6h7AhokVNalFhqKi3NtOoXdKRE0lmWU1ErVs3MW4FxaAaAQzVZxgN74McoC
         7/rCJ611A5/J4l0s9fbR4QxT7Si7ke4TsJyH/X6Wy2h/93yH87WbCUKeLOQT+mWUWmgu
         hNdXQOc73Uo+3bFMvSUy2cucxiG2FRZmUT4vPsTxe5jfWsZGeR40GGuTjCwWIjoQz/9P
         cp/RtyUgsUor2XGokKiMYaSV41Pgyhn/NVRwl4Kt5zUy7meftywJU26lKmdVbE4iqP68
         qfpw==
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=BxfaInJv9eQPb7hh67RBJX5kM1hvnpWM2R7azOu3K8Q=;
        b=EFH4egkQbz3DpbeJgB9VkuPVFpw+iodpoZtlDhGKdxonlpPAhzcbMpgNHUhrh/5d0G
         pwIOen2UnxV6TSmbAADAff4hTsJb/CLOAD5nOYSM7h7a2JN+OlruvQQRdbI9UNmYyst3
         x+1E72CAO6EMxvOeLXmAYn4Mednh2NXTIn1ueYbxN6LLAsctQKLnrw8rUzp+Ml76SIrp
         mzO6O/WmNdPomJHiHv0dYPJGWY8jWSMKv6gigkeF/v8baa8vygBXdhXbkxyMB9iyQv/d
         NeQPIVZtB68AJ/8RhiJ4zgXLbzfW+eklBW/tdxbS/mVQpIq/BB0zTA8x6ICHB6iqMWm6
         H/rg==
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: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
        by mx.google.com with ESMTP id y23si388304oti.65.2020.02.18.18.33.50;
        Tue, 18 Feb 2020 18:34:01 -0800 (PST)
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 S1728008AbgBSCdh (ORCPT <rfc822;ntypanski@gmail.com> + 99 others);
        Tue, 18 Feb 2020 21:33:37 -0500
Received: from mail.hallyn.com ([178.63.66.53]:49380 "EHLO mail.hallyn.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1726799AbgBSCdg (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 18 Feb 2020 21:33:36 -0500
Received: by mail.hallyn.com (Postfix, from userid 1001)
        id A9C4D8C6; Tue, 18 Feb 2020 20:33:33 -0600 (CST)
Date:   Tue, 18 Feb 2020 20:33:33 -0600
From:   "Serge E. Hallyn" <serge@hallyn.com>
To:     Christian Brauner <christian.brauner@ubuntu.com>
Cc:     =?iso-8859-1?Q?St=E9phane?= Graber <stgraber@ubuntu.com>,
        "Eric W. Biederman" <ebiederm@xmission.com>,
        Aleksa Sarai <cyphar@cyphar.com>, Jann Horn <jannh@google.com>,
        smbarber@chromium.org, Seth Forshee <seth.forshee@canonical.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        Serge Hallyn <serge@hallyn.com>,
        James Morris <jmorris@namei.org>,
        Kees Cook <keescook@chromium.org>,
        Jonathan Corbet <corbet@lwn.net>,
        Phil Estes <estesp@gmail.com>, linux-kernel@vger.kernel.org,
        linux-fsdevel@vger.kernel.org,
        containers@lists.linux-foundation.org,
        linux-security-module@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v3 02/25] proc: add /proc/<pid>/fsuid_map
Message-ID: <20200219023333.GB19144@mail.hallyn.com>
References: <20200218143411.2389182-1-christian.brauner@ubuntu.com>
 <20200218143411.2389182-3-christian.brauner@ubuntu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200218143411.2389182-3-christian.brauner@ubuntu.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Feb 18, 2020 at 03:33:48PM +0100, Christian Brauner wrote:
> The /proc/<pid>/fsuid_map file can be written once to setup an fsuid mapping
> for a user namespace. Writing to this file has the same restrictions as writing
> to /proc/<pid>/fsuid_map:
> 
> root@e1-vm:/# cat /proc/13023/fsuid_map
>          0     300000     100000
> 
> Fsid mappings have always been around. They are currently always identical to
> the id mappings for a user namespace. This means, currently whenever an fsid
> needs to be looked up the kernel will use the id mapping of the user namespace.
> With the introduction of fsid mappings the kernel will now lookup fsids in the
> fsid mappings of the user namespace. If no fsid mapping exists the kernel will
> continue looking up fsids in the id mappings of the user namespace. Hence, if a
> system supports fsid mappings through /proc/<pid>/fs*id_map and a container
> runtime is not aware of fsid mappings it or does not use them it will it will
> continue to work just as before.
> 
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Acked-by: Serge Hallyn <serge@hallyn.com>

> ---
> /* v2 */
> unchanged
> 
> /* v3 */
> - Christian Brauner <christian.brauner@ubuntu.com>:
>   - Fix grammar in commit message.
> ---
>  fs/proc/base.c | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index c7c64272b0fa..5fb28004663e 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2970,6 +2970,13 @@ static int proc_projid_map_open(struct inode *inode, struct file *file)
>  	return proc_id_map_open(inode, file, &proc_projid_seq_operations);
>  }
>  
> +#ifdef CONFIG_USER_NS_FSID
> +static int proc_fsuid_map_open(struct inode *inode, struct file *file)
> +{
> +	return proc_id_map_open(inode, file, &proc_fsuid_seq_operations);
> +}
> +#endif
> +
>  static const struct file_operations proc_uid_map_operations = {
>  	.open		= proc_uid_map_open,
>  	.write		= proc_uid_map_write,
> @@ -2994,6 +3001,16 @@ static const struct file_operations proc_projid_map_operations = {
>  	.release	= proc_id_map_release,
>  };
>  
> +#ifdef CONFIG_USER_NS_FSID
> +static const struct file_operations proc_fsuid_map_operations = {
> +	.open		= proc_fsuid_map_open,
> +	.write		= proc_fsuid_map_write,
> +	.read		= seq_read,
> +	.llseek		= seq_lseek,
> +	.release	= proc_id_map_release,
> +};
> +#endif
> +
>  static int proc_setgroups_open(struct inode *inode, struct file *file)
>  {
>  	struct user_namespace *ns = NULL;
> @@ -3176,6 +3193,9 @@ static const struct pid_entry tgid_base_stuff[] = {
>  	ONE("io",	S_IRUSR, proc_tgid_io_accounting),
>  #endif
>  #ifdef CONFIG_USER_NS
> +#ifdef CONFIG_USER_NS_FSID
> +	REG("fsuid_map",  S_IRUGO|S_IWUSR, proc_fsuid_map_operations),
> +#endif
>  	REG("uid_map",    S_IRUGO|S_IWUSR, proc_uid_map_operations),
>  	REG("gid_map",    S_IRUGO|S_IWUSR, proc_gid_map_operations),
>  	REG("projid_map", S_IRUGO|S_IWUSR, proc_projid_map_operations),
> -- 
> 2.25.0