All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Christian Brauner <brauner@kernel.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: Thu, 11 Jan 2024 16:53:19 -0500	[thread overview]
Message-ID: <20240111165319.4bb2af76@gandalf.local.home> (raw)
In-Reply-To: <20240111-unzahl-gefegt-433acb8a841d@brauner>

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:

static int eventfs_permission(struct mnt_idmap *idmap,
			      struct inode *inode, int mask)
{
	set_top_events_ownership(inode);
	return generic_permission(idmap, inode, mask);
}

Where the "set_top_events_ownership() is a nop for everything but the
"events" directory.

I guess I could have two ops:

static const struct inode_operations eventfs_root_dir_inode_operations = {
	.lookup		= eventfs_root_lookup,
	.setattr	= eventfs_set_attr,
	.getattr	= eventfs_get_attr,
	.permission	= eventfs_permission,
};

static const struct inode_operations eventfs_dir_inode_operations = {
	.lookup		= eventfs_root_lookup,
	.setattr	= eventfs_set_attr,
	.getattr	= eventfs_get_attr,
};

And use the second one for all dentries below the root, but I figured it's
not that big of a deal if I called the permissions on all. Perhaps I should
do it with two?

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.


-- Steve

  reply	other threads:[~2024-01-11 21:52 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 [this message]
2024-01-12  8:27                     ` Christian Brauner
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=20240111165319.4bb2af76@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=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=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 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.