From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Milian Wolff <milian.wolff@kdab.com>,
linux-perf-users <linux-perf-users@vger.kernel.org>
Subject: Re: /sys/kernel/tracing/events permissions
Date: Mon, 22 Nov 2021 15:37:39 -0300 [thread overview]
Message-ID: <YZvjc/0ObrVLbVCJ@kernel.org> (raw)
In-Reply-To: <20211122120155.780d0116@gandalf.local.home>
Em Mon, Nov 22, 2021 at 12:01:55PM -0500, Steven Rostedt escreveu:
> On Mon, 22 Nov 2021 12:02:37 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Em Mon, Nov 22, 2021 at 11:55:11AM +0100, Milian Wolff escreveu:
> > > a recent kernel update on my arch system has lead to breakage with regard to
> > > accessing trace events from perf. For example:
> Interesting. The change should have made the access to tracefs less
> restrictive, not more. Ah, I think it's the default permissions that caused
> this.
> > I saw some recent changes but haven't yet tried to reflect it into the
> > perf tools:
> > commit 79ef0c00142519bc34e1341447f3797436cc48bf
> > Merge: d54f486035fd89f1 feea69ec121f0670
> > Author: Linus Torvalds <torvalds@linux-foundation.org>
> > Date: Mon Nov 1 20:05:19 2021 -0700
> >
> > Merge tag 'trace-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
> >
> > Pull tracing updates from Steven Rostedt:
> > <SNIP>
> > - Have tracefs allow owner and group permissions by default (only
> > denying others). There's been pressure to allow non root to tracefs
> > in a controlled fashion, and using groups is probably the safest.
> > <SNIP>
> > > ```
> > > $ perf record -e sched:sched_switch ls
> > > event syntax error: 'sched:sched_switch'
> > > \___ can't access trace events
> > > Error: No permissions to read /sys/kernel/tracing/events/sched/sched_switch
> > > Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/tracing/'
> It's not the one commit, but the a clean up to not allow other access by
> default.
> To get the old access you need to add:
> sudo chmod -R o+r /sys/kernel/tracing
> sudo find /sys/kernel/tracing -type d -exec chmod o+x {} \;
> > > How should this be handled? Is it now required to manually `chmod` the
> > > `events` folder, or is there another means to allow non-root to record kernel
> > > trace events?
> > Rostedt, I looked for documentation for this on Documentation/trace/ but
> > couldn't find, so its just a matter of creating a 'tracing' group and
> > adding users to this group that then can use tracefs files?
> I should add that to the documentation.
> I believe the commit was the change to the default permissions (for group)
> and not for other.
> But to add a group, you can simply add:
> sudo addgroup tracing
> sudo chgrp -R /sys/kernel/tracing
sudo chgrp -R tracing /sys/kernel/tracing
> And if you only do the above (not the o+* commands explained earlier), then
> only those in the tracing group have access to tracefs.
Ok, I'll try to autodetect this new behaviour and provide a hint for the
recommended behaviour, to create a group and add users to it.
- Arnaldo
prev parent reply other threads:[~2021-11-22 18:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 10:55 /sys/kernel/tracing/events permissions Milian Wolff
2021-11-22 15:02 ` Arnaldo Carvalho de Melo
2021-11-22 17:01 ` Steven Rostedt
2021-11-22 18:37 ` Arnaldo Carvalho de Melo [this message]
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=YZvjc/0ObrVLbVCJ@kernel.org \
--to=acme@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=milian.wolff@kdab.com \
--cc=rostedt@goodmis.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 NNTP newsgroup(s).