From: Christian Brauner <brauner@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux Trace Kernel <linux-trace-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] tracefs/eventfs: Use root and instance inodes as default ownership
Date: Fri, 12 Jan 2024 09:27:24 +0100 [thread overview]
Message-ID: <20240112-normierung-knipsen-dccb7cac7efc@brauner> (raw)
In-Reply-To: <20240111165319.4bb2af76@gandalf.local.home>
On Thu, Jan 11, 2024 at 04:53:19PM -0500, Steven Rostedt wrote:
> On Thu, 11 Jan 2024 22:01:32 +0100
> Christian Brauner <brauner@kernel.org> wrote:
>
> > What I'm pointing out in the current logic is that the caller is
> > taxed twice:
> >
> > (1) Once when the VFS has done inode_permission(MAY_EXEC, "xfs")
> > (2) And again when you call lookup_one_len() in eventfs_start_creating()
> > _because_ the permission check in lookup_one_len() is the exact
> > same permission check again that the vfs has done
> > inode_permission(MAY_EXEC, "xfs").
>
> As I described in: https://lore.kernel.org/all/20240110133154.6e18feb9@gandalf.local.home/
>
> The eventfs files below "events" doesn't need the .permissions callback at
> all. It's only there because the "events" inode uses it.
>
> The .permissions call for eventfs has:
It doesn't matter whether there's a ->permission handler. If you don't
add one explicitly the VFS will simply call generic_permission():
inode_permission()
-> do_inode_permission()
{
if (unlikely(!(inode->i_opflags & IOP_FASTPERM))) {
if (likely(inode->i_op->permission))
return inode->i_op->permission(idmap, inode, mask);
/* This gets set once for the inode lifetime */
spin_lock(&inode->i_lock);
inode->i_opflags |= IOP_FASTPERM;
spin_unlock(&inode->i_lock);
}
return generic_permission(idmap, inode, mask);
}
> Anyway, the issue is with "events" directory and remounting, because like
> the tracefs system, the inode and dentry for "evnets" is created at boot
> up, before the mount happens. The VFS layer is going to check the
> permissions of its inode and dentry, which will be incorrect if the mount
> was mounted with a "gid" option.
The gid option has nothing to do with this and it is just handled fine
if you remove the second permission checking in (2).
You need to remove the inode_permission() code from
eventfs_start_creating(). It is just an internal lookup and the fact
that you have it in there allows userspace to break readdir on the
eventfs portions of tracefs as I've shown in the parts of the mail that
you cut off.
next prev parent reply other threads:[~2024-01-12 8:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 1:32 [PATCH] tracefs/eventfs: Use root and instance inodes as default ownership Steven Rostedt
2024-01-04 1:48 ` Al Viro
2024-01-04 2:25 ` Steven Rostedt
2024-01-04 4:39 ` Al Viro
2024-01-04 15:05 ` Steven Rostedt
2024-01-04 18:25 ` Al Viro
2024-01-04 19:10 ` Steven Rostedt
2024-01-04 19:21 ` Linus Torvalds
2024-01-04 19:15 ` Steven Rostedt
2024-01-04 19:26 ` Matthew Wilcox
2024-01-04 19:35 ` Linus Torvalds
2024-01-04 20:02 ` Linus Torvalds
2024-01-04 21:28 ` Al Viro
2024-01-04 19:03 ` Matthew Wilcox
2024-01-04 1:59 ` Al Viro
2024-01-04 2:17 ` Steven Rostedt
2024-01-05 14:26 ` Christian Brauner
2024-01-05 14:59 ` Steven Rostedt
2024-01-07 12:42 ` Christian Brauner
2024-01-07 17:42 ` Christian Brauner
2024-01-07 18:01 ` Christian Brauner
2024-01-07 18:29 ` Steven Rostedt
2024-01-07 18:32 ` Steven Rostedt
2024-01-08 11:32 ` Christian Brauner
2024-01-08 15:41 ` Steven Rostedt
2024-01-08 11:04 ` Christian Brauner
2024-01-08 15:23 ` Steven Rostedt
2024-01-10 11:45 ` Christian Brauner
2024-01-10 13:07 ` Steven Rostedt
2024-01-10 15:52 ` Steven Rostedt
2024-01-10 16:04 ` Steven Rostedt
2024-01-10 18:31 ` Steven Rostedt
2024-01-11 21:01 ` Christian Brauner
2024-01-11 21:53 ` Steven Rostedt
2024-01-12 8:27 ` Christian Brauner [this message]
2024-01-12 13:53 ` Steven Rostedt
2024-01-12 14:22 ` Steven Rostedt
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=20240112-normierung-knipsen-dccb7cac7efc@brauner \
--to=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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