Bug 204475
Summary: | Kernelshark-1.0 potentially does not support recording even when run as root | ||
---|---|---|---|
Product: | Tools | Reporter: | Mike Auty (mike.auty) |
Component: | Trace-cmd/Kernelshark | Assignee: | Default virtual assignee for Trace-cmd and kernelshark (tools_tracecmd_kernelshark) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | gletonai, rostedt, ykaradzhov |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.2.1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | Patch src/CMakeLists.txt for gentoo |
Description
Mike Auty
2019-08-04 12:08:43 UTC
Hi Mike, Thank you very much for reporting this issue! It seems to me that the problem is specific for the Linux distribution that you use, because typically pkexec file has read permissions. Nevertheless, If you want to use the "Record" dialog, you can still do this by directly starting it with Root privileges, bypassing the KernelShark GUI. You can start the dialog like this sudo kshark-record and than open the produced .dat file in kernelshark. Please note that we DO NOT RECOMMEND starting the KernelShark GUI as root. I guess we should even make this impossible. Once again thanks for the report! It will be great if you can provide here some additional information, like Cmake version, Linux distro etc. Cheers, Yordan Hiya, I use Gentoo, and it looks like it's got a hook to remove read from group and other when any setuid executable is installed. So the Makefile that ships with polkit would install it as 4755. I'm using polkit-0.116 and cmake-3.15.1. Thanks for the workaround, I'll give it a go. 5:) I'm fully with you on not running kernelshark-gui as root, I just wanted to verify if it detected privileges or was purely compilation check-based. I think people will be fine not being able to run it as root, since it should feel very similar to wireshark... I assume that kernelshark will still work if pkexec was present during compilation, but is not installed at runtime? If so, then presumably it could always assume pkexec exists, and then fail safely if it doesn't? I'm therefore not sure I understand why the compilation prevents calling out to pkexec? Anyway, thanks very much for your response, and please let me know if there's any further information or tests I can provide/run... 5:) I think it would be a good idea to have kernelshark detect that it is being run as root when it starts, and then post a "Warning" about running it as root, with a checkbox that states "don't show this message again", which when clicked, it wont. Then we set a global flag that says "I'm root". And when the user selects "Tools"->"Record", instead of calling pkexec, the kernelshark application will run kshark-record directly. Does that make sense? -- Steve Yes, it makes sense. I will try implementing it. Thanks! Y. Fixed by commit 2138faef74e (kernel-shark: Don't use pkexec when running as Root) Created attachment 293815 [details]
Patch src/CMakeLists.txt for gentoo
Gentoo users can use this patch, basically tells where pkexec is instead of finding it...
|