All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Marchevsky <davemarchevsky@fb.com>
To: <linux-fsdevel@vger.kernel.org>
Cc: Dave Marchevsky <davemarchevsky@fb.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Seth Forshee <sforshee@digitalocean.com>,
	Rik van Riel <riel@surriel.com>, <kernel-team@fb.com>
Subject: [PATCH] fuse: allow CAP_SYS_ADMIN in root userns to access allow_other mount
Date: Thu, 11 Nov 2021 14:11:42 -0800	[thread overview]
Message-ID: <20211111221142.4096653-1-davemarchevsky@fb.com> (raw)

Since commit 73f03c2b4b52 ("fuse: Restrict allow_other to the
superblock's namespace or a descendant"), access to allow_other FUSE
filesystems has been limited to users in the mounting user namespace or
descendants. This prevents a process that is privileged in its userns -
but not its parent namespaces - from mounting a FUSE fs w/ allow_other
that is accessible to processes in parent namespaces.

While this restriction makes sense overall it breaks a legitimate
usecase for me. I have a tracing daemon which needs to peek into
process' open files in order to symbolicate - similar to 'perf'. The
daemon is a privileged process in the root userns, but is unable to peek
into FUSE filesystems mounted with allow_other by processes in child
namespaces.

This patch adds an escape hatch to the descendant userns logic
specifically for processes with CAP_SYS_ADMIN in the root userns. Such
processes can already do many dangerous things regardless of namespace,
and moreover could fork and setns into any child userns with a FUSE
mount, so it's reasonable to allow them to interact with all allow_other
FUSE filesystems.

Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>
Cc: Seth Forshee <sforshee@digitalocean.com>
Cc: Rik van Riel <riel@surriel.com>
Cc: kernel-team@fb.com
---

Note: I was unsure whether CAP_SYS_ADMIN or CAP_SYS_PTRACE was the best
choice of capability here. Went with the former as it's checked
elsewhere in fs/fuse while CAP_SYS_PTRACE isn't.

 fs/fuse/dir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 0654bfedcbb0..2524eeb0f35d 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1134,7 +1134,7 @@ int fuse_allow_current_process(struct fuse_conn *fc)
 	const struct cred *cred;
 
 	if (fc->allow_other)
-		return current_in_userns(fc->user_ns);
+		return current_in_userns(fc->user_ns) || capable(CAP_SYS_ADMIN);
 
 	cred = current_cred();
 	if (uid_eq(cred->euid, fc->user_id) &&
-- 
2.30.2


             reply	other threads:[~2021-11-11 22:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 22:11 Dave Marchevsky [this message]
2021-11-12  2:10 ` [PATCH] fuse: allow CAP_SYS_ADMIN in root userns to access allow_other mount Rik van Riel
2021-11-12 10:13 ` Christian Brauner
2021-11-12 23:29   ` Dave Marchevsky
2021-11-15 15:28     ` Miklos Szeredi
2022-05-17 16:50       ` Dave Marchevsky
2022-05-18 11:22         ` Christian Brauner
2022-05-18 11:26           ` Miklos Szeredi
2022-05-19  4:56             ` Andrii Nakryiko
2022-05-19  8:59               ` Christian Brauner
2022-05-24  4:35                 ` Andrii Nakryiko
2022-05-24  7:07                   ` Miklos Szeredi
2022-05-24 14:59                     ` Rik van Riel
2022-05-24 15:44                     ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211111221142.4096653-1-davemarchevsky@fb.com \
    --to=davemarchevsky@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=riel@surriel.com \
    --cc=sforshee@digitalocean.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.