linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).