From patchwork Fri Mar 19 11:41:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 12150897 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1ADAC433DB for ; Fri, 19 Mar 2021 11:42:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A8B7364F70 for ; Fri, 19 Mar 2021 11:42:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229854AbhCSLmP (ORCPT ); Fri, 19 Mar 2021 07:42:15 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:42420 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229766AbhCSLmC (ORCPT ); Fri, 19 Mar 2021 07:42:02 -0400 Received: from ip5f5af0a0.dynamic.kabel-deutschland.de ([95.90.240.160] 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 1lNDVx-0006Mu-0N; Fri, 19 Mar 2021 11:42:01 +0000 From: Christian Brauner To: David Howells , linux-cachefs@redhat.com Cc: linux-fsdevel@vger.kernel.org, Christian Brauner Subject: [PATCH v3] cachefiles: do not yet allow on idmapped mounts Date: Fri, 19 Mar 2021 12:41:47 +0100 Message-Id: <20210319114146.410329-1-christian.brauner@ubuntu.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Based on discussions (e.g. in [1]) my understanding of cachefiles and the cachefiles userspace daemon is that it creates a cache on a local filesystem (e.g. ext4, xfs etc.) for a network filesystem. The way this is done is by writing "bind" to /dev/cachefiles and pointing it to the directory to use as the cache. Currently this directory can technically also be an idmapped mount but cachefiles aren't yet fully aware of such mounts and thus don't take the idmapping into account when creating cache entries. This could leave users confused as the ownership of the files wouldn't match to what they expressed in the idmapping. Block cache files on idmapped mounts until the fscache rework is done and we have ported it to support idmapped mounts. [1]: https://lore.kernel.org/lkml/20210303161528.n3jzg66ou2wa43qb@wittgenstein Cc: David Howells Cc: linux-cachefs@redhat.com Signed-off-by: Christian Brauner --- /* v2 */ - Christian Brauner : - Ensure that "root" is initialized when cleaning up. /* v3 */ - David Howells : - Reformulate commit message to avoid paragraphs with duplicated content. - Add a pr_warn() when cachefiles are supposed to be created on idmapped mounts. --- fs/cachefiles/bind.c | 6 ++++++ 1 file changed, 6 insertions(+) base-commit: 1e28eed17697bcf343c6743f0028cc3b5dd88bf0 diff --git a/fs/cachefiles/bind.c b/fs/cachefiles/bind.c index dfb14dbddf51..38bb7764b454 100644 --- a/fs/cachefiles/bind.c +++ b/fs/cachefiles/bind.c @@ -118,6 +118,12 @@ static int cachefiles_daemon_add_cache(struct cachefiles_cache *cache) cache->mnt = path.mnt; root = path.dentry; + ret = -EINVAL; + if (mnt_user_ns(path.mnt) != &init_user_ns) { + pr_warn("File cache on idmapped mounts not supported"); + goto error_unsupported; + } + /* check parameters */ ret = -EOPNOTSUPP; if (d_is_negative(root) ||