Bug 967354 - Impossible to uninstall polkit-pkla-compat
Impossible to uninstall polkit-pkla-compat
Product: Fedora
Classification: Fedora
Component: polkit-pkla-compat (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miloslav Trmač
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-05-26 15:31 EDT by David Zeuthen
Modified: 2013-05-27 09:05 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-27 09:05:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Zeuthen 2013-05-26 15:31:41 EDT
I'm trying to uninstall the polkit-pkla-compat package but this is causing the polkit package to be uninstalled which then causes most of the OS to be uninstalled. So, basically, the polkit-pkla-compat package is not optional.

FWIW (but I think you already know this), this package is very problematic it is causing a lot of extra processes to be created (at least one on *every* authorization check). The way it works *directly* contradicts what the polkit(8) man page says


namely "The spawn() method should be used sparingly [...]".

I'd really rather you didn't ship this in Fedora (I don't care what you do in RHEL). And if you really think that .pkla support is important (I've failed explaining to you and other that it's not) I'd rather you patch your polkit packages to do it without wasting processes power like this.

It's really quite disappointing that you are shipping this in the default install. Please don't do this. Thanks.
Comment 1 Miloslav Trmač 2013-05-27 09:05:14 EDT
Thanks for your report.

IMO, consistent results of the policy trump performance, and that's why polkit-pkla-compat needs to stay mandatory.

It would be great to improve the performace, however I don't currently have any more time to spend on this; patches would be definitely welcome.

(And re: the recommendation in polkit(8), it doesn't really apply because the pkla-* helpers can't run for a "very long or indeterminate amount of time", and polkitd does not handle other requests until the current one is answered ion any case, whether the answer is determined in C or JS).

FWIW, some numbers (average of 5 measurements, real time):
* (pkcheck --action-id org.freedesktop.locale1.set-keyboard --process $$)
  without polkit-pkla-compat: 27 ms
* The same with polkit-pkla-compat: 61.8 ms
  (OK, a non-trivial increase.)
* (pkla-check-authorization mitr true true org.freedesktop.locale1.set-keyboard)
  13.6 ms
* (pkla-admin-identities)
  10.6 ms
So as an unachievable lower bound, if the two helpers were replaced by a JavaScript code that took zero time to execute, the time for pkcheck could be improved to 37.6 ms.

One possible way to speed this up is to deviate polkit-pkla-compat further from the original code and to rip out all of the gio/gmonitor calls, with the goal of no longer linking with libgio (at least for pkla-admin-identities, 98% of the runtime is spent loading and initializing various libraries).

Another would be to add enough functionality to JS to actually allow implementing polkit-pkla-* in JS.

And the third is to call polkitbackendlocalauthority from inside the JS backend, which is architecturally really ugly.

Note You need to log in before you can comment on or make changes to this bug.