* Better support for temporarily elevating user permissions for perf
@ 2023-03-14 10:46 Milian Wolff
0 siblings, 0 replies; only message in thread
From: Milian Wolff @ 2023-03-14 10:46 UTC (permalink / raw)
To: linux-perf-users, acme
[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]
Hey all,
in hotspot [1] we provide a GUI to run `perf record`. To allow off-CPU profiling
without framepointers, we need to temporarily elevate the user permissions
such that one can access `sched:sched_switch` events.
[1]: https://github.com/KDAB/hotspot/
We do that with a pretty hacky script [2], which is even suffering from a
TOCTOU security bug. Now, fixing that is obviously not the point of this email,
rather I'm wondering if it would potentially be possible to add a proper way
upstream in perf to temporarily raise user permissions?
[2]: https://github.com/KDAB/hotspot/blob/master/scripts/
elevate_perf_privileges.sh
Basically, for `perf record`, there are three situations:
1. profile a new process group spawned by perf as a client application, but
accessing additional trace points:
perf record -e sched:sched_switch ./my_binary
2. attach to process owned by the current user, but accessing additional trace
points:
perf record -e sched:sched_switch -p 12345
3. attach to process not owned by current user, or doing system-wide profiling
perf record -a ...
Personally, I don't care much about 3), but 1) and 2) is something that I
frequently do, and it's also something that users of hotspot frequently do.
Sadly, this is not easily doable as a normal user. As such, it would be great
if we can find a way to better support this in a safe manner.
Temporarily chmod'ing the tracefs does not sound like a great idea. Rather, I
would prefer to just launch `perf` via pkexec or similar with elevated root
permissions. That works fine for 2) and 3) but it totally breaks 1) as the
client application spawned by perf should not be run as root.
Is there another way to safely implement this? The way I see it, this would
require some help from perf itself. Hypothetically, what we would need is
something like:
```
# as normal user
$ perf prepare-record ./my_binary
started process 12345, waiting for perf attach
```
This imaginary `perf prepare-record` would basically SIGSTOP itself right
before exec'ing `my_binary`. Then:
```
# as root
$ pkexec perf record --continue -p 12345 ...
attached to process 12345, sending SIGCONT
```
This would then setup perf profiling for the "prepared" process and once
everything is setup, sends the SIGCONT signal.
I do not think it's possible to implement this outside of perf. As such, would
the perf project accept such a solution? Or how would you like to see this
implemented?
Thanks a lot
--
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5272 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2023-03-14 10:54 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-14 10:46 Better support for temporarily elevating user permissions for perf Milian Wolff
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).