Just a note that because kernelshark uses cmake's find_program method to locate pkexec, if a normal user is building the program, and pkexec does not have read permissions for the user (because it is suid and only requires execute permissions) it is not detected. This is a known cmake issue #10468 [1] and I've asked for progress on there. kernelshark then cannot record, even when kernelshark is launched as root, because it has the "Record is currently not supported" error message compiled in, in place of the ability to record. Ideally, even if pkexec cannot be found, if the kernelshark process has the appropriate privileges to carry out the recording, it should. [1] https://gitlab.kitware.com/cmake/cmake/issues/10468
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...