From: Steven Rostedt <rostedt@goodmis.org>
To: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v8 3/6] tracefs: Check file permission even if user has CAP_DAC_OVERRIDE
Date: Tue, 24 Mar 2026 12:43:45 -0400 [thread overview]
Message-ID: <20260324124345.7fb9bda6@gandalf.local.home> (raw)
In-Reply-To: <177071303130.2293046.2400906233143699263.stgit@mhiramat.tok.corp.google.com>
On Tue, 10 Feb 2026 17:43:51 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
Hi Masami,
Did you send a new version of this patch series yet? I don't see it.
> diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
> index d9d8932a7b9c..eb1ddc0cc13a 100644
> --- a/fs/tracefs/inode.c
> +++ b/fs/tracefs/inode.c
> @@ -212,10 +212,40 @@ static void set_tracefs_inode_owner(struct inode *inode)
> inode->i_gid = gid;
> }
>
> -static int tracefs_permission(struct mnt_idmap *idmap,
> - struct inode *inode, int mask)
> +int tracefs_permission(struct mnt_idmap *idmap,
> + struct inode *inode, int mask)
> {
> - set_tracefs_inode_owner(inode);
> + struct tracefs_inode *ti = get_tracefs(inode);
> + const struct file_operations *fops;
> +
> + if (!(ti->flags & TRACEFS_EVENT_INODE))
> + set_tracefs_inode_owner(inode);
> +
> + /*
> + * Like sysfs, file permission checks are performed even for superuser
> + * with CAP_DAC_OVERRIDE. See the KERNFS_ROOT_EXTRA_OPEN_PERM_CHECK
> + * definition in linux/kernfs.h.
> + */
> + if (mask & MAY_OPEN) {
> + fops = inode->i_fop;
> +
> + if (mask & MAY_WRITE) {
> + if (!(inode->i_mode & 0222))
> + return -EACCES;
> + if (!fops || (!fops->write && !fops->write_iter &&
> + !fops->mmap))
> + return -EACCES;
> + }
> +
> + if (mask & MAY_READ) {
> + if (!(inode->i_mode & 0444))
> + return -EACCES;
> + if (!fops || (!fops->read && !fops->read_iter &&
> + !fops->mmap && !fops->splice_read))
> + return -EACCES;
> + }
The above if block is way too coupled with the workings of fops and is very
fragile. Is it even needed? If there are no read or write functions,
wouldn't the vfs stop it anyway?
-- Steve
> + }
> +
> return generic_permission(idmap, inode, mask);
> }
next prev parent reply other threads:[~2026-03-24 16:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-10 8:43 [PATCH v8 0/6] tracing: Remove backup instance after read all Masami Hiramatsu (Google)
2026-02-10 8:43 ` [PATCH v8 1/6] tracing: Fix to set write permission to per-cpu buffer_size_kb Masami Hiramatsu (Google)
2026-02-10 8:43 ` [PATCH v8 2/6] tracing: Reset last_boot_info if ring buffer is reset Masami Hiramatsu (Google)
2026-02-10 8:43 ` [PATCH v8 3/6] tracefs: Check file permission even if user has CAP_DAC_OVERRIDE Masami Hiramatsu (Google)
2026-02-11 15:46 ` Steven Rostedt
2026-02-12 6:15 ` Masami Hiramatsu
2026-03-05 17:33 ` Steven Rostedt
2026-03-24 16:43 ` Steven Rostedt [this message]
2026-02-10 8:43 ` [PATCH v8 4/6] tracing: Make the backup instance non-reusable Masami Hiramatsu (Google)
2026-02-10 8:44 ` [PATCH v8 5/6] tracing: Remove the backup instance automatically after read Masami Hiramatsu (Google)
2026-02-10 8:44 ` [PATCH v8 6/6] tracing/Documentation: Add a section about backup instance Masami Hiramatsu (Google)
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=20260324124345.7fb9bda6@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox