From patchwork Tue Oct 13 11:07:39 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sargun Dhillon X-Patchwork-Id: 11835435 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id F0059109B for ; Tue, 13 Oct 2020 11:07:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB9EF20659 for ; Tue, 13 Oct 2020 11:07:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=sargun.me header.i=@sargun.me header.b="muAXyrqM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730365AbgJMLHy (ORCPT ); Tue, 13 Oct 2020 07:07:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33138 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730196AbgJMLHw (ORCPT ); Tue, 13 Oct 2020 07:07:52 -0400 Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AED2AC0613D5 for ; Tue, 13 Oct 2020 04:07:51 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id n9so17313225pgf.9 for ; Tue, 13 Oct 2020 04:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sargun.me; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=DsdLLXEDu5r/rHvGHkVF/s17QLEI/N8JfwaZzVE4yB4=; b=muAXyrqMq62Izrg81/t4ptqj8Swn6SKvqTxUpJ+Zymn2DlKWCBAP1GI8ZXFU8m/vF+ 8ENY23F4hgI+I0T+JSo9L0FAsL8oIyp1oDKU/keoZNuykXCwiuzJlH6Y/2PaGbtimepH 63f+EH740kSXvrWZR9Nd/2m+UT1zZiNl33bPg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=DsdLLXEDu5r/rHvGHkVF/s17QLEI/N8JfwaZzVE4yB4=; b=N+SOocihfaw9EaG9eCm+Eat498Rj3VuuPyGNR5WX0pIMWyj72UDh072FFkq8AwsbHX CEW8AgQnYrxltGe+YGWRSaPinjAq1bBl3yX03A35DTnLqFonpKMs87+5cJyeBDm3u5DY kh6mkXz1mvh9X/Y0p2QXqrNiz9qWdOh1oVB0VwYQVwMEvDZe5SRxNgMfvHjqnFx99fI4 409lZdCPFf8nRHtbQn6xjvzGUsrQF/Fngijsvzr+Cb5p3ULitLtv2a1zvNFbEzCHrF78 4vKDLswtQyiIDFpnBEgr2T0UUYlDQkebaisXabCUeD3l78R3rnyrPZiuwctGqKBAxRq3 ufuQ== X-Gm-Message-State: AOAM530idmb9SGPLQjWaJ34f0zQdK0JLlTH29pVDFb7sInCrqNTazAzG TrT+rrc8CN2xFZZ1t3G6VOjMLw== X-Google-Smtp-Source: ABdhPJzqgEV+lAzcTt/anrFL0qbSxvROzpd/Bgfp7nsuzar5JhMOWGYQzIRZJvmrVNrusgjQNu/0lg== X-Received: by 2002:a65:4987:: with SMTP id r7mr16649379pgs.228.1602587270915; Tue, 13 Oct 2020 04:07:50 -0700 (PDT) Received: from ubuntu.netflix.com (203.20.25.136.in-addr.arpa. [136.25.20.203]) by smtp.gmail.com with ESMTPSA id f5sm20809195pgi.86.2020.10.13.04.07.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Oct 2020 04:07:50 -0700 (PDT) From: Sargun Dhillon To: "J . Bruce Fields" , Chuck Lever , Trond Myklebust , Anna Schumaker Cc: Sargun Dhillon , linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH] nfs: Use cred from fscontext during fsmount Date: Tue, 13 Oct 2020 04:07:39 -0700 Message-Id: <20201013110739.21922-1-sargun@sargun.me> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org This is a subtle change that is important for usage of NFS within user namespaces. With the new mount APIs, the fscontext has an associated struct cred. This struct cred is created at the time "fsopen" is called. This cred object contains user namespaces, network namespaces, etc... Right now, rather than using the cred / network namespace / user namespaces that are all acquired at the time fsopen is called, we use some bits at the time FSCONFIG_CMD_CREATE is called, and other bits at the time fsopen is called. Specifically, the RPC client itself lives in the network namespace that fsopen was called within. On the other hand, the credentials the RPC client uses are the ones retrieved at the time of FSCONFIG_CMD_CREATE. When FSCONFIG_CMD_CREATE is called, the vfs layer checks is the user has CAP_SYS_ADMIN in the init user ns, as NFS does not have the FS_USERNS_MOUNT flag enabled. Due to this, there is no way of configuring an NFS mount to use id mappings from a user namespace. It may make sense to switch from using clp->cl_rpcclient->cl_cred->user_ns as the user namespace for the idmapper to clp->cl_net->user_ns, to make sure that everything is aligned based on the net ns, and matches what has been previously discussed [1]. Although this is a change that would effect userspace, it is very unlikely that anyone is initializing the NFS FS FD in an unprivileged namespace, and then calling FSCONFIG_CMD_CREATE to only get the network namespace's effects, and not all of the effects. The fscontext API has provisions for being able to configure specific namespaces. [1]: https://lore.kernel.org/linux-nfs/CAMp4zn-mw1U3PoS9k_JePieU2+owg6hdXdrQ2Lt3p173J_sRbg@mail.gmail.com/ Signed-off-by: Sargun Dhillon --- fs/nfs/client.c | 2 +- fs/nfs/nfs4client.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/nfs/client.c b/fs/nfs/client.c index 4b8cc93913f7..bd26ec6a2984 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -985,7 +985,7 @@ struct nfs_server *nfs_create_server(struct fs_context *fc) if (!server) return ERR_PTR(-ENOMEM); - server->cred = get_cred(current_cred()); + server->cred = get_cred(fc->cred); error = -ENOMEM; fattr = nfs_alloc_fattr(); diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c index daacc78a3d48..818638cb10c4 100644 --- a/fs/nfs/nfs4client.c +++ b/fs/nfs/nfs4client.c @@ -1151,7 +1151,7 @@ struct nfs_server *nfs4_create_server(struct fs_context *fc) if (!server) return ERR_PTR(-ENOMEM); - server->cred = get_cred(current_cred()); + server->cred = get_cred(fc->cred); auth_probe = ctx->auth_info.flavor_len < 1;