linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milian Wolff <milian.wolff@kdab.com>
To: linux-perf-users@vger.kernel.org, acme@kernel.org
Subject: Better support for temporarily elevating user permissions for perf
Date: Tue, 14 Mar 2023 11:46:23 +0100	[thread overview]
Message-ID: <3838922.9otfd4vPil@milian-workstation> (raw)

[-- 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 --]

                 reply	other threads:[~2023-03-14 10:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=3838922.9otfd4vPil@milian-workstation \
    --to=milian.wolff@kdab.com \
    --cc=acme@kernel.org \
    --cc=linux-perf-users@vger.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 NNTP newsgroup(s).