PolicyKit + KDE

Andreas Pakulat apaku at gmx.de
Wed Sep 2 22:02:07 BST 2009

On 02.09.09 21:19:01, Dario Freddi wrote:
> In data mercoledì 02 settembre 2009 20:53:34, Andreas Pakulat ha scritto:
> > The problem is that some things where (are?) set to be installed outside of
> > KDE's prefix, more importantly it tried to install into a location that is
> > not writeable by an ordinary user. As kauth has (hopefully) gone through a
> > review process before moving it to kdelibs it suggests that this was
> > intentional because anything else wouldn't work with policykit. At least
> > thats the thoughts I had.
> KAuth was in kdereview for 3 weeks more than 2 months ago IIRC, so it's gone 
> through quite a long review.

Ah, right, now that I looked up the archive it comes back to memory :)
Unfortunately it seems nobody cared about the cmake-related things, too bad
but I can't blame anybody (except myself).

> Yes, the paths were intentional as otherwise the 
> feature would not work, and *HINT*KDE has no policy regarding files that need 
> a specific prefix*HINT*.

Actually it has: Do _NOT_ install outside of the installation prefix
(there's one exception).

> KAuth is not the only one having this kind of 
> problems: see python engine in KDEbase.

No, it doesn't. Well it does currently, but thats because the maintainers
refuse to just print out the warning and accept the bugreports from users
that don't know they need to adjust their PYTHONPATH. Python does provide a
really easy way of having python modules outside of specific paths.

If polkit doesn't provide a way to do that (I'm not asking anyone to give me
directions on that, I'm sure I can find that myself), its incomplete in my
opinion. BTW, I still don't know wether polkit actually doesn't support
that or wether this whole discussion is moot because polkit already has
ways of allowing root to add arbitrary paths where it searches for its
files. (and yes I'm too lazy to find that out)

> So the problem is quite like: what do we need to do if some files require
> a specific path and do not work outside of it?

Fix the software that doesn't allow me to put its files into arbitrary
locations.  This is a _really_ common thing around linux, distributions
install KDE into /opt/kde. Companies/Universities/... building their own
version and installing it into /usr/local/kde/<version>. Developers trying
to work on multiple KDE versions installing to $HOME/kde<version> or
something like that.
> > Hmm, a mv? Sorry thats not a solution, can polkit not be configured to find
> > its policy files elsewhere than /usr? I'd really like to use the related
> > features, but I'm not going to interrupt my packaging system for that (and
> > moving stuff to /etc or /usr is exactly that).
> AFAIK, polkit 0.9 cannot do that, at least not in the config files, there 
> could be a build option. I suggest to report a feature request in PolicyKit 
> )fd.o) defining the problem

Do you have a bugzilla url at hand?

> > Maybe broken is a bit hard, incomplete might be better. I consider any
> > software forcing me to screw with my packaging system to add something to
> > it at least incomplete (tbh I consider it broken, but thats just my
> > opinion).
> The problem is not not letting people to install stuff elsewhere, it's more 
> about security. Anyway the right route to take would be 1. having a policy for 
> this kind of situations (check with kde-buildsystem)

As Thiago already said, the policy is to not install outside of the install
prefix. I'm not sure wether its written down anywhere, but this has been
the case since at least KDE 3.2 (the first version I've installed into my

> 2. eventually request a feature in polkit, if it does not support this in
> the very upcoming polkit 1.0 (that actually should be in and ready for
> kde 4.4)

Yeap, see above, I'll be happy to submit that but I'm not really up digging
through fd.o's bugzilla to find the right place (IIRC its even worse than
ours). I'm also not sure wether I'm the right person to discuss this with
them as I have absolutely 0 idea about Polkit (except what its supposed to


Don't kiss an elephant on the lips today.

More information about the kde-core-devel mailing list