Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2060330ybv; Fri, 14 Feb 2020 10:40:22 -0800 (PST) X-Google-Smtp-Source: APXvYqwuqbxD6+ad4boE0pKHkQKmNMG1TSb10tEZ86KoqQruEqEdw0jqowSF+YzkvZKcCkse1517 X-Received: by 2002:a05:6830:1317:: with SMTP id p23mr3388147otq.3.1581705622446; Fri, 14 Feb 2020 10:40:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581705622; cv=none; d=google.com; s=arc-20160816; b=RcgdtDuPwZAXBMRr/SIAiPClftbguf+Ut3LsDQvXzxxwI9gVaD/1KOQSqF29nbG609 XINuWFH1b7gmO8kLbCIRvRB8uPuw6lac1htIkmK7yV63OtAYX2Vte7dVoylgJGJsfIy4 vuNoKUd2L/o3aB+igQimY4jp0exTRTq6C/UWemV7B6dWLhy3AUcZTqVTQrgqbAc6pKKN MNvxttZps2yhUICVGMbJPmATzgY4YgXDyjTwVbe9ocAqa533RpMyEHXyCb4DpyTdzsfq GXStl5NpeYXqFTfhzcLaCkMLO5bI4XwCrwrbgfN3pPuKyfLxQkrJsmIbIVULscTvZYTY s/SQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=UreIC/ddZ769HIyIecEwTYrzZLJWNv9t6JG8SYdI0lk=; b=wNX4G/cB+1k731sw1LNiJJG/Xacx4JMq6yhvyVrIH5xFXZrvMIVv31FsjmmjFwL7TU 0VHp5XBhTHYNYoYy99Mk95Thtp3wYTUJLApHSLJzR3rCv3SXpFkAb9um1BL823kuAhfV 1T8ePVne+k5sB7aMelhZf9AMYqfHP6ZImOgmIpyDPgIcdbU6crFId9szbSKbw3Prf0KY HuTEtGmU0xH6GKKs9f9ns8WtsT7sybh++Qe3NU5Qhy1LGNgAdAF7mkBKOrMkFKp0weky 7K/40+vqKBh8766mPZ4B73WJVKTZ6rhttqmPA2lExRExs1DX7TmJYB2/6C3cMMkVIEuf Hkig== 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 p1si3251606otk.42.2020.02.14.10.40.10; Fri, 14 Feb 2020 10:40:22 -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 S2390432AbgBNSil (ORCPT + 99 others); Fri, 14 Feb 2020 13:38:41 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:33678 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730588AbgBNSiC (ORCPT ); Fri, 14 Feb 2020 13:38:02 -0500 Received: from ip5f5bf7ec.dynamic.kabel-deutschland.de ([95.91.247.236] helo=wittgenstein.fritz.box) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1j2fqQ-0000uO-N8; Fri, 14 Feb 2020 18:37:42 +0000 From: Christian Brauner To: =?UTF-8?q?St=C3=A9phane=20Graber?= , "Eric W. Biederman" , Aleksa Sarai , Jann Horn Cc: smbarber@chromium.org, Seth Forshee , Alexander Viro , Alexey Dobriyan , Serge Hallyn , James Morris , Kees Cook , Jonathan Corbet , Phil Estes , 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, Christian Brauner Subject: [PATCH v2 09/28] sys:__sys_setuid(): handle fsid mappings Date: Fri, 14 Feb 2020 19:35:35 +0100 Message-Id: <20200214183554.1133805-10-christian.brauner@ubuntu.com> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200214183554.1133805-1-christian.brauner@ubuntu.com> References: <20200214183554.1133805-1-christian.brauner@ubuntu.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Switch setuid() to lookup fsids in the fsid mappings. If no fsid mappings are setup the behavior is unchanged, i.e. fsids are looked up in the id mappings. The kfsid to cleanly handle userns visible filesystem is set as before. We require that a user must have a valid fsid mapping for the target id. This is consistent with how the setid calls work today without fsid mappings. Signed-off-by: Christian Brauner --- /* v2 */ - Christian Brauner : - set kfsid which is used when dealing with proc permission checking --- kernel/sys.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/sys.c b/kernel/sys.c index 864fa78f25a7..a8eefd748327 100644 --- a/kernel/sys.c +++ b/kernel/sys.c @@ -574,11 +574,16 @@ long __sys_setuid(uid_t uid) struct cred *new; int retval; kuid_t kuid; + kuid_t kfsuid; kuid = make_kuid(ns, uid); if (!uid_valid(kuid)) return -EINVAL; + kfsuid = make_kfsuid(ns, uid); + if (!uid_valid(kfsuid)) + return -EINVAL; + new = prepare_creds(); if (!new) return -ENOMEM; @@ -596,7 +601,8 @@ long __sys_setuid(uid_t uid) goto error; } - new->fsuid = new->euid = kuid; + new->kfsuid = new->euid = kuid; + new->fsuid = kfsuid; retval = security_task_fix_setuid(new, old, LSM_SETID_ID); if (retval < 0) -- 2.25.0