Bug 229735 - Installing KDE in "/usr/KDE-4.4 breaks Authorization.
Summary: Installing KDE in "/usr/KDE-4.4 breaks Authorization.
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdecore (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Dario Freddi
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-06 22:09 UTC by James Richard Tyrer
Modified: 2010-11-09 17:27 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Richard Tyrer 2010-03-06 22:09:03 UTC
Version:            (using KDE 4.4.1)
Compiler:          GCC 4.3.3 
OS:                Linux
Installed from:    Compiled From Sources

It appears that installing KDE-4.4.1 in a directory other than: "/usr" breaks KAuth,

When I open: "SystemSettings -> Advanced -> PolicyKit Authorization", there is no tree rooted with: "org.kde".
Comment 1 Dario Freddi 2010-03-07 12:09:31 UTC
It's a known "bug/feature" - also a warning is being spit out at cmake time. PolicyKit/polkit simply does not support installing policies out of /usr.
Comment 2 James Richard Tyrer 2010-03-08 11:35:55 UTC
Your brief and unintelligible comment is the reason that I had stopped filing bug reports on KDE.

To simply say that this is not KDE's problem because it is a problem with polkit is not correct.  KDE incorporated a new library without proper testing and it has broken things.  This legitimately makes one question the competence of the KDE developers.  Didn't anyone test it before the release?  If you knew it was broken and it was released anyway, that is even worse.

My suggestion is that KDE should take responsibility for the problem and supply a patch for PolicyKit and polkit to fix the problem.

What I find with Google is arguing about security issues.  There is an easy way to screen files for security.  Make sure that they are owned by root:root with permissions 644 or less.  Personally, I would have liked to have seen this use XDG_DATA_DIRS but since D-Bus doesn't, it appears that it would be best to have separate configuration files: /etc/PolicyKit/PolicyKit.conf and /etc/polkit-1/nullbackend.conf.d/*-nullbackend.conf.  

The point is that this needs to be fixed now, rather than making excuses that it is someone else's problem!

I also note that it is not satisfactory that this configuration can not be changed without restarting the messagebuss daemon.  And, local configuration files are needed.
Comment 3 Dario Freddi 2010-03-08 13:19:47 UTC
I hope you're realizing you're bitching in the wrong place. It's like saying when you develop a certain software, you should go out and fix all the bugs you find in the lower level stack, and we simply don't have enough resources for that, like nobody does. Go ahead and tell any developer he has to fix an annoyance (because this is mostly an annoyance and not a bug) deep down in the stack he's relying upon and he'll give you a proper reply.

You say - incorporated without proper testing and breaking things - which is totally incorrect and a fantasy of yours. DBus works the very same way, go figure. When dealing with root privileges, some things deep in the stack have restricted policies the developers do not like to change. So either accept this or write your own framework, I'll be happy to write a backend for KAuth for it. And I'll try repeating for the 1000000th time that depending on polkit is not compulsory.

However, you might be happy to note that this issue has been _extensively_ discussed before both on kde-core-devel and the polkit mailing list, as you found out. So if you also have a solution, my question is: why do you report it here? It's not an excuse that it's somebody else's problem: it's the reality. I don't even have a git account on fd.o. Even if I had a patch ready, I could not even push it. So you probably just need to chill down and write what you wrote here somewhere else, like polkit-devel or bugs.fd.org, maybe with a better tone, because _NOTHING_ of what you wrote is related to KDE.
Comment 4 James Richard Tyrer 2010-03-08 20:49:40 UTC
No, I am complaining in the correct place.  From what I have read, KDE has a problem with this, therefore, if FD.o won't fix it, someone needs to make a patch and post it on the KDE FTP servers.  You don't need a FD.o account to do that.

You seem to think that I am just bitching.  This is not the case.  This problem is not only a problem for developers, it is a problem for users.  The build instructions on TechBase are now useless.  I will have to post a warning that if you build KDE-4.4 according to my tutorial it won't work.  That is not just an annoyance!  Having a lot of features broken is not just an annoyance, is it?

I have to say that you are whining.  I have heard this before from developers that don't seem to have any sense of personal responsibility as lton as they can talk down the problem or blame someone else.  It is KDE that will have its reputation further damaged by this problem.  To me, it is simple.  KDE chose to use this library.  You say that a user doesn't have to use it, but doesn't that mean that things won't work?  Because KDE chose to use this library, it becomes KDE's problem and KDE needs to see that it is fixed.

If you hired me to build something for your and there was a problem because I used defective materials, what would you think if I told you that it wasn't my problem?  And don't use the canard that this is free software so the users shouldn't complain.  That doesn't cut it with users.  If KDE is going to make a product, they should take responsibility for its quality -- doesn't matter that it is free.  It should be a matter of personal pride and personal responsibility to see that the KDE team delivers a high quality product.
Comment 5 Dario Freddi 2010-03-08 21:09:18 UTC
(In reply to comment #4)
> No, I am complaining in the correct place.  From what I have read, KDE has a
> problem with this, therefore, if FD.o won't fix it, someone needs to make a
> patch and post it on the KDE FTP servers.  You don't need a FD.o account to do
> that.

I hope you are joking

> 
> You seem to think that I am just bitching.  This is not the case.  This problem
> is not only a problem for developers, it is a problem for users.  The build
> instructions on TechBase are now useless.  I will have to post a warning that
> if you build KDE-4.4 according to my tutorial it won't work.  That is not just
> an annoyance!  Having a lot of features broken is not just an annoyance, is it?

There is a warning at cmake time. What are the "lot" of features you are missing? Changing date/time and killing processes running as root? Please. And you can still move files around.

> 
> I have to say that you are whining.  I have heard this before from developers
> that don't seem to have any sense of personal responsibility as lton as they
> can talk down the problem or blame someone else.  It is KDE that will have its
> reputation further damaged by this problem.  To me, it is simple.  KDE chose to
> use this library.  You say that a user doesn't have to use it, but doesn't that
> mean that things won't work?  Because KDE chose to use this library, it becomes
> KDE's problem and KDE needs to see that it is fixed.

Simple answer: No. So you say that we should have not supported nvidia drivers in 4.0 or fix drivers ourselves? This is not how this world works, where everyone has his software and his responsabilities.

> 
> If you hired me

Nice point. IF you hired me.

> to build something for your and there was a problem because I
> used defective materials, what would you think if I told you that it wasn't my
> problem?  And don't use the canard that this is free software so the users
> shouldn't complain.  That doesn't cut it with users.  If KDE is going to make a
> product, they should take responsibility for its quality -- doesn't matter that
> it is free.  It should be a matter of personal pride and personal
> responsibility to see that the KDE team delivers a high quality product.

And do you think you are able to fix defective materials? I wouldn't be so stupid to tell you to fix something you can't fix yourself, but report the problem to the manifacturer. Exactly what you are NOT doing.

Or I would tell you to change manifacturer. Guess what, in this case there is not another one available. So what you do? Live with the problem. It's you against a full userbase and developer base who understood the issue instead of coming up with arguments that make no sense at all and accusing KDE of things which are completely out of our responsibilities, I hope you are realizing this.

And I'm tired of telling you this because you'll keep refusing this argument. You have a completely distorted vision of how things work when developing software, maintainers exist for a reason. And bugs should be reported to them.

P.S.: I'm not the maintainer of polkit and will never be. And I doubt I will contribute to it as well.
P.P.S.: Can you please file the same bug against any other application using polkit? I don't like KDE being the only one. NetworkManager, HAL and DeviceKit are the first on the list. It seems reasonable from what you are saying, correct?
Comment 6 Dr.Edgar Alwers 2010-03-09 05:20:40 UTC
(In reply to comment #5)
> 
> There is a warning at cmake time. What are the "lot" of features you are
> missing? Changing date/time and killing processes running as root? Please. And
> you can still move files around.
> 
Just a few points: as I have the wrong timezone, I am not able to operate my finance programs. I am at the moment in south-America, my laptop is still showing european time. And I cannot do anything, because I am not allowed to change the time. It is _my_ laptop, and I am not even allowed to change a simple time !! I have on another partition a kde-3.5 version. This was my luck here ! Please do not underestimate the problems James is talking about !
Edgar
Comment 7 Dario Freddi 2010-03-09 12:34:42 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > 
> > There is a warning at cmake time. What are the "lot" of features you are
> > missing? Changing date/time and killing processes running as root? Please. And
> > you can still move files around.
> > 
> Just a few points: as I have the wrong timezone, I am not able to operate my
> finance programs. I am at the moment in south-America, my laptop is still
> showing european time. And I cannot do anything, because I am not allowed to
> change the time. It is _my_ laptop, and I am not even allowed to change a
> simple time !! I have on another partition a kde-3.5 version. This was my luck
> here ! Please do not underestimate the problems James is talking about !
> Edgar

I'm not understimating the problem. I am trying to tell him that he's looking for a fix in the wrong place.

Btw, if you wanted a fix so badly, here it comes:

sudo cp $KDEPREFIX/share/polkit/actions/* /usr/polkit/actions
sudo cp $KDEPREFIX/share/dbus-1/system-services/* /usr/share/dbus-1/system-services
sudo cp $KDEPREFIX/etc/dbus-1/system.d/* /etc/dbus-1/system.d

I'd love to point out that out of these three paths, two are from DBus and one is from polkit. So - guess what? - the problem is widespread in the fd.o stack. And you know you can't even install the plasma python engine in a different prefix as well, do you? I think you can see the point now. And copying some files is not rocket science.
Comment 8 Dr.Edgar Alwers 2010-03-09 18:45:33 UTC
> (In reply to comment #6)
> 
> Btw, if you wanted a fix so badly, here it comes:
> 
> sudo cp $KDEPREFIX/share/polkit/actions/* /usr/polkit/actions
> sudo cp $KDEPREFIX/share/dbus-1/system-services/*
> /usr/share/dbus-1/system-services
> sudo cp $KDEPREFIX/etc/dbus-1/system.d/* /etc/dbus-1/system.d

OK. I have kde-4.4.0 installed in /opt/kde-4.4. The result of your advice ( thank you very much for your hints ) was not successfull:

1.) There does not exist an /opt/kde-4-4/share/polkit directory. However, as we instaled PolicyKit-0.9 and polkit-0.96 in /usr, it exists an /usr/share/polkit-1/actions/ directory. Following your hint, we created an /usr/polkit/actions directory, and cp the contents of the corresponding /usr/share/polkit-1/actions/ to it. Just to remind: we are alredy talking about polkit, policykit and polkit-1 and guessing directories.

2.) sudo cp $KDEPREFIX/share/dbus-1/system-services/* /usr/share/dbus-1/system-services: OK. Done

3.) sudo cp $KDEPREFIX/etc/dbus-1/system.d/* /etc/dbus-1/system.d OK. done

The result of all, after rebooting, trying to modify the time:
"You are not allowed to save the configuration"

> And you know you can't even install the plasma python engine in a different
> prefix as well, do you? I think you can see the point now. And copying some
> files is not rocket science.

Let me please make some additional comments:

1. We should slow down the discussion. We all are only trying to get KDE-4.4 running smootly, helping in the way each one of us can. I e.g. as experienced user.

2. If very important programs are running under kde-3.5 and suddenly not more under kde-4.4 due to safety issues, and I am not able and allowed to make the necessary changes ( time ), then kde-4.4 has a problem.

3. Part of the problem is the inconsistency of sources. Sometimes trunk, sometimes kdesupport, sometimes git. And the versions are not compatible.

4. There are not explanations about PolicyKit, polkit, polkit-qt, polkit-qt-1.
Are they all compatible ? or are they excluding each other perhaps ? But these programs seem to be ruling the authorization issues !

5.) last but not least, also you could observe, that copying files may advance to a rocket science.

I don't believe, that the intention of the KDE-developers is to develop only for distributor companies. There are thousands of self building users. I am one, pretty well experienced. The system, at this moment, needs more attention in this sense.

Edgar
Comment 9 Dario Freddi 2010-03-09 19:38:53 UTC
(In reply to comment #8)
> > (In reply to comment #6)
> 
> OK. I have kde-4.4.0 installed in /opt/kde-4.4. The result of your advice (
> thank you very much for your hints ) was not successfull:
> 
> 1.) There does not exist an /opt/kde-4-4/share/polkit directory. However, as we
> instaled PolicyKit-0.9 and polkit-0.96 in /usr, it exists an
> /usr/share/polkit-1/actions/ directory. Following your hint, we created an
> /usr/polkit/actions directory, and cp the contents of the corresponding
> /usr/share/polkit-1/actions/ to it. Just to remind: we are alredy talking about
> polkit, policykit and polkit-1 and guessing directories.

Sorry, my bad. it was
sudo cp $KDEPREFIX/share/polkit-1/actions/* /usr/polkit-1/actions

I wrote this in a hurry. However, this is valid if you are using polkit-1 as KAuth's backend. If you did not specify anything explicitely and you have both polkit and PolicyKit installed, it's quite likely PolicyKit got chosen, since it's the default of KDE 4.4. However cmake's output in kdelibs should tell you what's being built. If you have PolicyKit as a backend, the command is

sudo cp $KDEPREFIX/share/PolicyKit/policy/* /usr/PolicyKit/policy

> The result of all, after rebooting, trying to modify the time:
> "You are not allowed to save the configuration"

Expected, as the action dir was wrong. Please retry with the hints from above.

> 
> > And you know you can't even install the plasma python engine in a different
> > prefix as well, do you? I think you can see the point now. And copying some
> > files is not rocket science.
> 
> Let me please make some additional comments:
> 
> 1. We should slow down the discussion. We all are only trying to get KDE-4.4
> running smootly, helping in the way each one of us can. I e.g. as experienced
> user.

I know, and I can assure you I am not that rude usually. But I don't like getting attacked for no reasons, as you can read above. If a decent attitude was shown in the first place I would have reacted differently. It was not so hard after all.

You guys should realize that we don't write a poem in answer to a bug report because we are repeating the same thing over and over - and in our free time. I felt really insulted by such an attitude, like I think everyone would have.

> 
> 2. If very important programs are running under kde-3.5 and suddenly not more
> under kde-4.4 due to safety issues, and I am not able and allowed to make the
> necessary changes ( time ), then kde-4.4 has a problem.

Yes, but still (as you can see) you can fix that by moving some files. Probably this should be added somewhere (I repeated this hint a gazillion times to a lot of people but never got written anywhere), and it makes sense, as if you are compiling software from source dealing with this kind of stuff (root privileges and stuff), moving some files is a decent compromise. Otherwise you might end up (see the conclusion of the mail) installing permissions allowing you to perform actions as root as a normal user - not really making sense, isn't it?

> 
> 3. Part of the problem is the inconsistency of sources. Sometimes trunk,
> sometimes kdesupport, sometimes git. And the versions are not compatible.

Uhm, I did not get this actually. What are you talking about in specific?

> 
> 4. There are not explanations about PolicyKit, polkit, polkit-qt, polkit-qt-1.
> Are they all compatible ? or are they excluding each other perhaps ? But these
> programs seem to be ruling the authorization issues !

Please read my blogpost about that, which is quite explainatory:
http://drfav.wordpress.com/2009/12/22/polkit-and-kde-lets-make-the-point-of-the-situation/
Unfortunately this has been due to reasons external to KDE: however KAuth (hence KDE apps) supports both of them, but still ONLY ONE will be used, and this is decided at compile time in KDELIBS (and you can force it, please read documentation in kdelibs/kdecore/auth/ConfigureChecks.cmake or simply have a look at your CMake cache).

This is what we did to shield us from the polkit disaster, and we managed it quite well. So again, after all the work (a lot, I might add) that came into making both dependencies pluggable and optional, hearing that apparently "I don't care" is extremely frustrating, because you really don't want to know what would have happened if KAuth did not exist and polkit/PolicyKit was a hard dependency. We in KDE are in an extremely privileged situation regarding this matter now, and this has been achieved using KDE technologies only. So we _do_ care about our users here.

> 
> 5.) last but not least, also you could observe, that copying files may advance
> to a rocket science.

Well, I assume that if you created such a situation, you are able to compile from source to a different prefix than default, hence you are surely more than able to move some files around :)

> 
> I don't believe, that the intention of the KDE-developers is to develop only
> for distributor companies. There are thousands of self building users. I am
> one, pretty well experienced. The system, at this moment, needs more attention
> in this sense.

I can't agree with you here - as you have seen, I can do nothing more than adding this part myself to the "compilation from source" tutorial, and I hope you realize this. There is no way of fixing this situation in DBus and polkit/PolicyKit, and I doubt the situation will change in the future. That's the point I'm trying to state.

This -has had attention-, and a lot: there has been a wide discussion over this. A first idea, that was scratched, was to force the prefix to /usr, but we preferred to stay this way to allow people to build wherever they wanted, and just spit out a phat warning at cmake time. So we _do_ care about this.

Still, there are some good reasons for polkit and dbus to have the configuration handled this way - even the "solution" proposed by James won't really work, and still would require you to issue "make install" as superuser, which you surely don't want if you're installing KDE to your home directory, for example.

So the best solution to the problem is simply installing wherever, and moving those files.

BTW, the proof to all of this is that I compile KDE to ~/kde, just like you. And I have authorizations & stuff working, as you might imagine, just by moving files installed in those three directories. I agree the process could be documented better and I would be happy if you could point me to the relevant documentation so that I can update it.

You know, if the second message had been "Ok, can you please tell me if there is a fix for this?", probably we wouldn't be talking and wasting each other's time right now. But that's how it goes.
Comment 10 Dario Freddi 2010-03-09 19:45:10 UTC
Oh, btw, all of this belongs to kdelibs nevertheless.
Comment 11 Dr.Edgar Alwers 2010-03-11 00:47:39 UTC
Thank you very much for the explanations, Dario, especially for the blogpost article explaining the different systems.
I build again kdelibs with your recommended configuration:
cmake -DCMAKE_INSTALL_PREFIX=/opt/kde-4.4/ -DKAUTH_BACKEND=PolkitQt-1
/sources-kde44/kdelibs/

Extract from the configuration:

-- Building PolkitQt-1 KAuth backend 
-- The following external packages were located on your system.              
-- This installation will have the extra features provided by these packages.
-----------------------------------------------------------------------------
.....
   * PolkitQt-1 - Qt Wrapper around polkit-1

I did
sudo cp $KDEPREFIX/share/polkit-1/actions/* /usr/polkit-1/actions

but I had to create /usr/polkit-1/actions. Thereis only one file there:
org.kde.kcontrol.kcmremotewidgets.policy

Well, and in short, after rebooting, nothing happened.Still the dammed 
"You are not allowed to save the configuration"

I tried to change the timezone with an "export TZ=Europe/Berlin" in /etc/profile, but this does not work on KDE-settings : current local time zone Factory ( CET )

Could you give me a way, different from kdesettings, to change this in Europe/Berlin ? That would give me more time to solve the general issue.

And, perhaps you could give me more detailed indications, what files should I
find in those directories ? It shouldn't be as difficult ! Help very appreciated !
Edgar
Comment 12 Dario Freddi 2010-03-11 08:45:42 UTC
(In reply to comment #11) 
> I did
> sudo cp $KDEPREFIX/share/polkit-1/actions/* /usr/polkit-1/actions
> 

ARGH - sorry, I have to be completely stupid, I missed the "share".
It's /usr/share/polkit-1/actions
This time is right, I promise :)

drf@drfarch:~$ ls /usr/share/polkit-1/actions/
org.chakraproject.aqpm.policy                           org.freedesktop.policykit.policy  org.kde.kcontrol.kcmclock.policy            org.qt.policykit.examples.policy
org.freedesktop.consolekit.policy                       org.gnome.gconf.defaults.policy   org.kde.kcontrol.kcmremotewidgets.policy
org.freedesktop.network-manager-settings.system.policy  org.kde.auth.example.policy       org.kde.ksysguard.processlisthelper.policy
org.freedesktop.packagekit.policy                       org.kde.fontinst.policy           org.kde.polkitkde1.policy
Comment 13 Dr.Edgar Alwers 2010-03-11 20:37:43 UTC
> ARGH - sorry, I have to be completely stupid, I missed the "share".
> It's /usr/share/polkit-1/actions
> This time is right, I promise :)
> 
> drf@drfarch:~$ ls /usr/share/polkit-1/actions/
> org.chakraproject.aqpm.policy                          
> org.freedesktop.policykit.policy  org.kde.kcontrol.kcmclock.policy           
> org.qt.policykit.examples.policy
> org.freedesktop.consolekit.policy                      
> org.gnome.gconf.defaults.policy   org.kde.kcontrol.kcmremotewidgets.policy
> org.freedesktop.network-manager-settings.system.policy 
> org.kde.auth.example.policy       org.kde.ksysguard.processlisthelper.policy
> org.freedesktop.packagekit.policy                       org.kde.fontinst.policy
>           org.kde.polkitkde1.policy

Hi Dario,

thanks for the replay. However, the result was again negative. I think, we are facing another kind of problem, as I only have three of your *.policy files on my PC: org.kde.kcontrol.kcmremotewidgets.policy, org.freedesktop.consolekit.policy,
org.freedesktop.policykit.policy
Especially nothing like org.kde.kcontrol.kcmclock.policy or any kde related policys was found. 
What should I do to add this items in my system ? Thank you again very much.
Edgar
Comment 14 Dario Freddi 2010-03-11 20:51:56 UTC
The relevant files are installed by kdebase - especially if you recompiled kdelibs with polkit-1 support, you need a clean rebuild+install of kdebase, and then perform the move (don't forget the other 2 moves in addition to the policy files).
Comment 15 Dr.Edgar Alwers 2010-03-15 01:07:58 UTC
(In reply to comment #14)
> The relevant files are installed by kdebase - especially if you recompiled
> kdelibs with polkit-1 support, you need a clean rebuild+install of kdebase, and
> then perform the move (don't forget the other 2 moves in addition to the policy
> files).

Problems and more problems. After rebuilding kdebase I get now a message from kdm: "A critical error ocurred Look at kdm logfiles"
kdm log is"(EE) Failed to initialize GLX extension (compatible nvidia x driver not found)".
Could you give me a hint here ? I just build kdebase ! and the system was working smoothly until polkit's efforts !
TIA again,
Edgar
Comment 16 James Richard Tyrer 2010-03-16 03:45:32 UTC
I am reopening this because I think that it might be a KDE problem.  It is not necessary to move the files to configure D-Bus.  I note that there are 4 D-Bus directories what should be addressed.  These can be taken care of by adding or editing the two s*-local.conf files in: "/etc/dbus-1".  So, I have that done.

IIUC, the "*.policy" files must be installed in the appropriate sub-directories of $PREFIX/share where $PREFIX is the prefix where PolicyKit and PolKit are installed.  This should be accomplished by using the CMake parameter:

-DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy

and the "*.policy" files were installed in that directory, except for one: "org.kde.kcontrol.kcmremotewidgets.policy".  Could that be a bug?  IAC, I linked to to be sure.

Now, thing have improved.  When I open SystemSettings and go to: "Advanced -> PolicyKit Authorization", the KDE policies now show up in the tree view in a tree rooted with "org.kde".  And, the notice in the "Date & Time" now says that I will be required to authenticate when I save.

HOWEVER, it still doesn't work.  I can't save a change in time zone.  In fact, the button: "Apply" remains grayed out.  Unless there is something else that I need to do, I have to conclude that this *is* a KDE problem.  Or, perhaps I need to install: PolKit-Qt and PolKit-Qt-1 with a PREFIX of "/usr" as well, but that would be a KDE problem, wouldn't it.
Comment 17 Dario Freddi 2010-03-16 09:40:28 UTC
(In reply to comment #16)
> IIUC, the "*.policy" files must be installed in the appropriate sub-directories
> of $PREFIX/share where $PREFIX is the prefix where PolicyKit and PolKit are
> installed.  This should be accomplished by using the CMake parameter:
> 
> -DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy
> 
> and the "*.policy" files were installed in that directory, except for one:
> "org.kde.kcontrol.kcmremotewidgets.policy".  Could that be a bug?  IAC, I
> linked to to be sure.

Yup, it is, probably a problem while bootstrapping.

> 
> Now, thing have improved.  When I open SystemSettings and go to: "Advanced ->
> PolicyKit Authorization", the KDE policies now show up in the tree view in a
> tree rooted with "org.kde".  And, the notice in the "Date & Time" now says that
> I will be required to authenticate when I save.
> 
> HOWEVER, it still doesn't work.  I can't save a change in time zone.  In fact,
> the button: "Apply" remains grayed out.  Unless there is something else that I
> need to do, I have to conclude that this *is* a KDE problem.  Or, perhaps I
> need to install: PolKit-Qt and PolKit-Qt-1 with a PREFIX of "/usr" as well, but
> that would be a KDE problem, wouldn't it.

Polkit-Qt* do not need to be installed to the same prefix. 99/100, if the button is greyed out, is for one of the following reason:

 - You don't have the action file in your system. You seem like you do , however the action dir is the PolicyKit one. Can you please check kdelibs is being built with Polkit-Qt as a backend and not with Polkit-Qt-1? (cmake says it)
 - You don't have consolekit running, hence the default policy prevents you from saving. Can you please check if your kdm has been compiled with consolekit support? If you're logging in without kdm that's another story instead. If that's the case you could:
  - Either spawn ck manually when launching kde (if you google around some people do that)
  - Either change the system policies to let you authorize even if you're not on any console.
Comment 18 James Richard Tyrer 2010-03-31 21:22:58 UTC
I have done considerable work on this.  I know have KDE-4.4 BRANCH installed with:

-DCMAKE_INSTALL_PREFIX:PATH=/usr/KDE-4.4 \
-DSYSCONF_INSTALL_DIR=/etc/kde-4.4 \
-DKDE4_AUTH_POLICY_FILES_INSTALL_DIR:STRING=/usr/share/PolicyKit/policy

I note that I built KAuth with PolicyKit although I do have polkit installed.

I configured the D-Bus configuration according to the tutorial:

http://techbase.kde.org/Getting_Started/Tutorials/D-Bus/Configuration

It doesn't work correctly.  When I try to change the date (to test it), the: "Authenticate" dialog appears.  I enter the root password and click the: "Authenticate" button and I get this error message: 

"Unable to authenticate/execute the action: 7, DBus Backend error: could not contact the helper. Connection error: Could not get owner of name 'org.kde.kcontrol.kcmclock': no such name. Message error: Failed to setup environment correctly"

Since D-Bus is correctly configured, this appears to be a KDE bug.  Specifically, it appears that something in KDELibs is trying to find the file: 

/usr/KDE-4.4/share/dbus-1/system-services/org.kde.kcontrol.kcmclock.service

without using the D-Bus API.
Comment 19 Dario Freddi 2010-03-31 21:39:57 UTC
No, the file you mentioned is a descriptor for a DBus autostart service (which is exactly the helper you want to start), so there are no APIs involved or stuff, DBus starts the service specified in that file automagically. Apparently, DBus is not looking for autostart system services in that specific dir.

If you want to install it to /usr/KDE-4.4 instead of /usr, you have to tell DBus to look for autostart system services in that specific dir as well (unfortunately I have no idea on how to do that).
Comment 20 James Richard Tyrer 2010-04-02 19:40:28 UTC
(In reply to comment #19)
> No, the file you mentioned is a descriptor for a DBus autostart service (which
> is exactly the helper you want to start), so there are no APIs involved or
> stuff, 

Perhaps the error message isn't that clear.  Or, are you simply saying that API was a poor choice of words?

> DBus starts the service specified in that file automagically.

Apparently not.

> Apparently, DBus is not looking for autostart system services in that specific
> dir.
> 
Yes, that does appear to be the problem.

> If you want to install it to /usr/KDE-4.4 instead of /usr, you have to tell
> DBus to look for autostart system services in that specific dir as well
> (unfortunately I have no idea on how to do that).

Then perhaps you should read the tutorial:

http://techbase.kde.org/Getting_Started/Tutorials/D-Bus/Configuration

The tutorial contains a workaround.  Therefore, there is a bug.  It seems pointless to argue about whether it is a KDE issue or a D-Bus issue since the fact is that they do not work correctly together and that problem needs to be corrected.
Comment 21 Dario Freddi 2010-04-02 19:58:20 UTC
If there is a bug, I surely don't have enough details to help you out here. You should debug and find out why the service is not started by DBus (this supposed bug, which I'm pretty sure is a misconfiguration since DBus autostart is what makes your whole system work, is surely on DBus side).

Also: this is not a bug of interaction between KDE and DBus, because this is a core DBus functionality. DBus autostart services work pretty much like KService. You definitely have to find out why the service is not started in the first place.
Comment 22 James Richard Tyrer 2010-04-02 21:55:46 UTC
Did you read the information on KDE TechBase?

Setting the: CONFIG_INSTALL_DIR to something other than the $PREFIX where D-Bus is installed results in default install locations for "*.service" files where D-Bus cannot find needed them and cannot really be properly configured to find them -- editing a file which you are not supposed to edit is not considered proper configuration.

Also, although the build system does have the:

DBUS_SERVICES_INSTALL_DIR

parameter, it lacks a corresponding paramater for: 

$PREFIX/share/dbus-1/system-services

So, it is not possible for the user to choose that install directory.
Comment 23 Dario Freddi 2010-04-03 13:06:03 UTC
(In reply to comment #22)
> Did you read the information on KDE TechBase?
> 
> Setting the: CONFIG_INSTALL_DIR to something other than the $PREFIX where D-Bus
> is installed results in default install locations for "*.service" files where
> D-Bus cannot find needed them and cannot really be properly configured to find
> them -- editing a file which you are not supposed to edit is not considered
> proper configuration.

Let me remind you that you are messing with stuff that sells out for free root privileges - hence there is quite a barrier for configuring this kind of stuff, and DBus does it this way by design.

> 
> Also, although the build system does have the:
> 
> DBUS_SERVICES_INSTALL_DIR
> 
> parameter, it lacks a corresponding paramater for: 
> 
> $PREFIX/share/dbus-1/system-services
> 
> So, it is not possible for the user to choose that install directory.

From KDE4Macros.cmake

install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${HELPER_ID}.service
                DESTINATION ${DBUS_SYSTEM_SERVICES_INSTALL_DIR})

So you can definitely set DBUS_SYSTEM_SERVICES_INSTALL_DIR and change the path. Remember that what you want to change are _system_ autostart services, and not session ones (which is what the other variable you mentioned does).
Comment 24 Dario Freddi 2010-11-09 17:27:17 UTC
I think this bug should be closed, as everything that should have been said has been said, and it is not active since long.