Version: unspecified (using Devel) OS: Linux I'm on KDE SC 4.5 RC2. I selected "Recent SVN or Snapshot Version" as "KDE Version" for this bug report because RC2 or 4.4.92 is not listed at all as a choice. I'm trying to change the KDM configuration. Since there doesn't seem to be a way to do that from the KDE GUI, I have to resort to the terminal and do: kdesu systemsettings However, when I hit "Apply" nothing happens. When I then try to quit systemsettings, it tells me that I didn't apply the settings. I hit "Apply" there too, but I get an error dialog saying: Unable to authenticate/execute the action: (code 2) Reproducible: Always Steps to Reproduce: Run "kdesu systemsettings". Change any "Login Manager" setting and hit "Apply". Quit, and in the dialog that pops up hit "Apply". Actual Results: Error message. Expected Results: Applying of new settings. Gentoo AMD64 Kernel 2.6.34.1 Qt 4.7.0 Beta 2 KDE SC 4.5 RC2 (4.4.92)
The message "Unable to authenticate/execute the action: (code 2)" likely means there is a problem with your PolicyKit, KAuth, D-Bus or ConsoleKit installations. Unfortunately I don't know too much about them. Adding KAuth maintainer.
(In reply to comment #1) > The message "Unable to authenticate/execute the action: (code 2)" likely means > there is a problem with your PolicyKit, KAuth, D-Bus or ConsoleKit > installations. I do not have PolicyKit nor ConsoleKit installed. I don't know what "KAuth" is. D-Bus is installed (1.2.24). Note that this is the same setup I had with KDE SC 4.4.4 (which I was using previously) and it was working fine.
First of all, DO NOT start systemsettings as root - this won't help you solve the issue here. The whole point of this system is to avoid starting up applications as root so you don't need - and shouldn't - do that. That said, that particular error code means that there is an installation problem - possibly your distribution is packaging KDE out of /usr and forgot to move some files around. I wouldn't be surprised if starting systemsettings as standard user, as it should, you wouldn't be able to click "Apply" at all - which leads us to the very root of the problem. So this is a clear packaging bug: polkit files are out of place and the corresponding action cannot be found. To be completely sure about that, you might want to post here the following things: ldd $KDEPREFIX/lib/kde4/plugins/kauth/backend/kauth_backend_plugin.so ls /usr/share/PolicyKit/policy/ ls /usr/share/polkit-1/actions/ Which would tell why and where your installation is broken. In the meanwhile I'm filing the bug as invalid, as it's a packaging problem in 99,9% of the cases.
I have just seen that you're using Gentoo, so I assume you're self compiling your packages. If that is the case and you did not install polkit or PolicyKit, the system is expected not to work, as they are required at build time AND at runtime for granting root permissions. You should have a polkit-1 package somewhere - you might want to install it, rebuild the whole kde, and try again. A sure way to find this out is ldd $KDEPREFIX/lib/kde4/plugins/kauth/backend/kauth_backend_plugin.so - if it's not linking to anything polkit/policykit, then what you reported is an expected behavior, as you don't have any component which allows you to escalate privileges.
(In reply to comment #4) > I have just seen that you're using Gentoo, so I assume you're self compiling > your packages. If that is the case and you did not install polkit or PolicyKit, > the system is expected not to work, as they are required at build time AND at > runtime for granting root permissions. It was never required during build time. Compilation succeeded just fine. I suppose if this is required, the build should abort with an appropriate error message. > You should have a polkit-1 package > somewhere There are three. "policykit-kde", "policykit-qt" and "policykit". I'll install them and recompile KDE. But again, I think in this case, if this stuff isn't optional, the build should abort or else you get confused users who were never told they need those extra packages; like me :-) > A sure way to find this out is > ldd $KDEPREFIX/lib/kde4/plugins/kauth/backend/kauth_backend_plugin.so - if it's > not linking to anything polkit/policykit, then what you reported is an expected > behavior, as you don't have any component which allows you to escalate > privileges. Well, the sure way to find out is that polkit isn't installed and kauth_backend_plugin.so doesn't even exist :-) About escalating privileges: I was using sudo and kdesu for this, which was working just fine with KDE 4.4.
(In reply to comment #5) > It was never required during build time. Compilation succeeded just fine. I > suppose if this is required, the build should abort with an appropriate error > message. Yes, sorry, I was not very clear: it is not a hard requirement :) Possibly we should be more verbose about that, but the proposal of making it an hard requirement have been actually discarded. The bottom line is: it is required as long as you want this feature (and you usually do), but it's not required to make KDE build. > There are three. "policykit-kde", "policykit-qt" and "policykit". I'll > install them and recompile KDE. But again, I think in this case, if this stuff > isn't optional, the build should abort or else you get confused users who were > never told they need those extra packages; like me :-) Install policykit-qt first, and when you're done with rebuilding kdelibs, install policykit-kde, which is the best combination to get the whole system working without hassle. > > > A sure way to find this out is > > ldd $KDEPREFIX/lib/kde4/plugins/kauth/backend/kauth_backend_plugin.so - if it's > > not linking to anything polkit/policykit, then what you reported is an expected > > behavior, as you don't have any component which allows you to escalate > > privileges. > > Well, the sure way to find out is that polkit isn't installed and > kauth_backend_plugin.so doesn't even exist :-) Ok, then this is spot on :) > About escalating privileges: I > was using sudo and kdesu for this, which was working just fine with KDE 4.4. That's correct - because KDE 4.4 did not have this feature - at least not in KDM. You would probably have encountered the very same problem if you tried to change date/time through systemsettings in KDE 4.4.x.
Oh, and btw, just to stress the point again: once you rebuild everything and have 4.5 set up, forget about using sudo, because everything's already done for you. KAuth is a system which escalates a smaller helper application protected through an authorization framework, instead of starting a whole GUI as root, so the whole prcedure is way easier and more secure. P.S.: After a full rebuild w/ polkit, you might need to restart your KDM or even better restart your system and retry. If you're not using KDM to log in, you have to start ConsoleKit manually, but you can google for this and find a solution in a matter of seconds.
Thanks for the info. I just checked and Gentoo actually has a USE flag for PolicyKit. If I enable that, the package manager automatically triggers a rebuild of all packages affected. I guess I'll drop the Gentoo packagers a note about this so that they can print a warning when installing KDE with this flag disabled. It's just that I thought "kdesu systemsettings" is actually *supposed* to work just like in 4.4, which is why I thought this is a valid bug. Sorry for the noise.
No noise - what you reported is actually more than reasonable. I'll try working on some better solution to advertise this problem at runtime if it ever happens again, thanks :)