From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH v3 0/6] tracefs/eventfs: Fix inconsistent permissions
Date: Thu, 02 May 2024 16:08:21 -0400 [thread overview]
Message-ID: <20240502200821.125580570@goodmis.org> (raw)
The tracefs and eventfs permissions are created dynamically based
on what the mount point inode has or the instances directory inode has.
But the way it worked had some inconsistencies that could lead to
security issues as the file system is not behaving like admins would
expect.
The files and directories could ignore the remount option that changes
the gid or uid ownerships, leaving files susceptable to access that
is not expected. This happens if a file had its value changed previously
and then a remount changed all the files permissions. The one that
was changed previously would not be affected.
This change set resolves these inconsistencies.
This also fixes the test_ownership.tc test as it would pass on the
first time it is run, but fail on the second time, because of the
inconsistant state of the permissions. Now you can run that test
multiple times and it will always pass.
Changes since v2: https://lore.kernel.org/linux-trace-kernel/20240502151547.973653253@goodmis.org/
- The eventfs_inode freeing was incorrect. The kref_put() would call
release_ei() that freed the contents of the eventfs_inode then
call kfree_rcu() on the eventfs_inode itself. The contents of the
eventfs_inode needs to be freed after the RCU synchronization as
well. The patches here add even more cases where that's a requirement.
- Add a iput callback for the tracefs_inode to clear the TRACEFS_EVENT_INODE
flag. This will prevent the clearing of flags in remount to go into
the eventfs_remount() function. A RCU grace cycle happens between
the clearing of this flag and where the eventfs_inode is freed, so
it is OK if the iteration is happening at the same time, as it is
done under rcu_read_lock().
Changes since v1: https://lore.kernel.org/linux-trace-kernel/20240502030024.062275408@goodmis.org/
- Testing showed that taking a mutex when freeing the tracefs_inode
caused a lockdep splat as it can happen in the RCU softirq context.
Convert the mutex to a spinlock for adding and removing the node
from the link list, and free the node via call_rcu() so that the
iteration of the list only needs to be protected by rcu_read_lock().
Steven Rostedt (Google) (6):
eventfs: Free all of the eventfs_inode after RCU
tracefs: Reset permissions on remount if permissions are options
tracefs: Still use mount point as default permissions for instances
eventfs: Do not differentiate the toplevel events directory
eventfs: Do not treat events directory different than other directories
eventfs: Have "events" directory get permissions from its parent
----
fs/tracefs/event_inode.c | 127 ++++++++++++++++++++++++++++-------------------
fs/tracefs/inode.c | 92 ++++++++++++++++++++++++++++++++--
fs/tracefs/internal.h | 14 ++++--
3 files changed, 175 insertions(+), 58 deletions(-)
next reply other threads:[~2024-05-02 20:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 20:08 Steven Rostedt [this message]
2024-05-02 20:08 ` [PATCH v3 1/6] eventfs: Free all of the eventfs_inode after RCU Steven Rostedt
2024-05-02 20:08 ` [PATCH v3 2/6] tracefs: Reset permissions on remount if permissions are options Steven Rostedt
2024-05-02 20:08 ` [PATCH v3 3/6] tracefs: Still use mount point as default permissions for instances Steven Rostedt
2024-05-02 20:08 ` [PATCH v3 4/6] eventfs: Do not differentiate the toplevel events directory Steven Rostedt
2024-05-02 20:08 ` [PATCH v3 5/6] eventfs: Do not treat events directory different than other directories Steven Rostedt
2024-05-02 20:08 ` [PATCH v3 6/6] eventfs: Have "events" directory get permissions from its parent 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=20240502200821.125580570@goodmis.org \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).