> On Sept. 15, 2016, 1:29 a.m., Aleix Pol Gonzalez wrote: > > processcore/helper.cpp, line 133 > > <https://git.reviewboard.kde.org/r/128909/diff/2/?file=476882#file476882line133> > > > > `KAUTH_HELPER_MAIN` doesn't work on OS X? > > René J.V. Bertin wrote: > Thanks for picking up on this, I'd forgotten to make a comment about it. > > I think the macro does work, it's KAuth which currently doesn't seem to > work for me. It also doesn't in my Linux build, btw, but there at least it > gives some error output suggesting tries to use polkit and possibly even the > processlist helper from my KDE4 desktop. > > The explicit implementation on OS X wasn't because of the macro, it was > to allow running setuid root. Initial testing didn't show any benefit to > that, but it could well be that's because KAuth still fails somewhere and > then simply aborts the requested operation. > > Suggestions very welcome, but if we can't get this to work I'll probably > want to disable changing process priorities. > > René J.V. Bertin wrote: > As to testing with setuid root: it looks it won't be trivial to hack > KAuth out of helper.cpp . Is there a way to take KAuth out of the loop one > way or another - for instance instruct it to do nothing when already running > with the required privileges, or to ignore failures? > > I'm fully aware why Qt disables running setuid root, but I'd hope the > risk is minimal in a helper app like this that is designed to work as root > (and doesn't "linger"). > > Also, the helper is started via DBus, right? Doesn't DBus provide a > mechanism to launch a service with elevated privileges? > > René J.V. Bertin wrote: > FWIW, after I uninstalled the KDE4 helper app from my Linux system > (`apt-get remove ksysguard`) I started getting the same error as I see on OS > X when I try to increase a process's priority: > > ``` > kf5.kauth: Tried to start an invalid action > kf5.kauth: Tried to start an invalid action > ``` > > After reinstalling the KDE4 ksysguard package all errors went away and > the feature works. Go figure ... > (I don't have KDE4 ksysguard installed on OS X) > > Aleix Pol Gonzalez wrote: > I suggest dropping the workaround for now and investigate how to get > KAuth to work altogether then. > > René J.V. Bertin wrote: > Not really related, but yeah I guess you're right. > > FWIW, on OS X I see this: > > ``` > > KAuthHelperTest -vb -v2 > [...] > INFO : HelperTest::testExecuteJobSignals() > QVERIFY(job->data().isEmpty()) > Loc: > [/opt/local/var/macports/build/_Volumes_Debian_MP9_site-ports_kf5_KF5-Frameworks/kf5-kauth/work/kauth-5.24.0/autotests/HelperTest.cpp(184)] > PASS : HelperTest::testExecuteJobSignals() > INFO : HelperTest::testActionData() entering > INFO : HelperTest::testActionData() QVERIFY(action.isValid()) > Loc: > [/opt/local/var/macports/build/_Volumes_Debian_MP9_site-ports_kf5_KF5-Frameworks/kf5-kauth/work/kauth-5.24.0/autotests/HelperTest.cpp(199)] > INFO : HelperTest::testActionData() QCOMPARE(action.status(), > KAuth::Action::AuthRequiredStatus) > Loc: > [/opt/local/var/macports/build/_Volumes_Debian_MP9_site-ports_kf5_KF5-Frameworks/kf5-kauth/work/kauth-5.24.0/autotests/HelperTest.cpp(201)] > QWARN : HelperTest::testActionData() QSocketNotifier: Socket notifiers > cannot be enabled or disabled from another thread > ^C > QFATAL : HelperTest::testActionData() Received signal 2 > Function time: 5229ms Total time: 7337ms > FAIL! : HelperTest::testActionData() Received a fatal error. > Loc: [Unknown file(0)] > Totals: 3 passed, 1 failed, 0 skipped, 0 blacklisted > ********* Finished testing of HelperTest ********* > Exit 1 > ``` > > That's at least 1 thing that doesn't work as it should; not yet sure what > this has to do with the failures I'm seeing (the socket error is > platform-agnostic so the KAuth OS X code does cross-thread stuff the Linux > code apparently doesn't ... unless it's libdbus that uses threading) > ).
Well ... it turns out I had never "back"ported my modifications to KDE4's Auth Services to KAuth, nor had anybody else in the 2 years since they were committed. https://git.reviewboard.kde.org/r/126086/ However, that doesn't fix everything. I now have a ksysguard app that obtains authorisation to do whatever it is it wants to do, and that then raises a DBus connection error because it is designed to use a helper for that purpose, which apparently fails to connect (I think it isn't even launched). It seems ksysguard was never designed with platforms in mind where authorisation isn't obtained through a helper that's controlled via DBus. Technically that *should* work on OS X, but in practice KAuth would probably better do without. What's the better approach here? Modify the ksysguard helper app so that it's started as a regular helper app and then obtains authorisation on its own? Or rewrite ksysguard so that it doesn't use a helper at all? IMHO, the interest here is much more in providing an example for other applications (and me learning a few new tricks) rather than getting niceness control to work on OS X. BTW, the scheduler changes should be disabled; can that be done independently from the niceness control? - René J.V. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128909/#review99182 ----------------------------------------------------------- On Sept. 15, 2016, 2:47 p.m., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128909/ > ----------------------------------------------------------- > > (Updated Sept. 15, 2016, 2:47 p.m.) > > > Review request for KDE Base Apps and KDE Software on Mac OS X. > > > Repository: libksysguard > > > Description > ------- > > This patch implements initial and rather minimal support for OS X, for now > focussing purely on process information. That feature is justified as it is > used by KDevelop in order to obtain the list of processes one can attach a > debugger to. > > Mac OS X is tricky because it requires special privileges in order to obtain > certain types of information for any running process. For example, even > obtaining the number of threads spawned by a foreign process requires > privileges that aren't trivial to set up. I've prepared the terrain, but also > implemented a fallback strategy that calls `ps` to be sure that crucial > information like the command name is available for all processes. > > > Diffs > ----- > > processcore/CMakeLists.txt e7c9263 > processcore/Info.plist PRE-CREATION > processcore/processes_darwin_p.cpp PRE-CREATION > processcore/processes_local_p.cpp 2bc123f > > Diff: https://git.reviewboard.kde.org/r/128909/diff/ > > > Testing > ------- > > On OS X 10.9.5 with Frameworks 5.24.0 and Qt 5.6.1 > > > File Attachments > ---------------- > > Attach to Process widget in KDevelop > > https://git.reviewboard.kde.org/media/uploaded/files/2016/09/14/47468811-58cb-40b8-a735-4dd86dce98e1__Screen_Shot_2016-09-14_at_17.38.22.png > > > Thanks, > > René J.V. Bertin > >
