I am (still) compiling latest kde from trunk, but I still don't see button or root menu options where a user can log in as an administrator temporarily to perform root level actions.

An example would be in the KDM interface or the kdenetworking interface. There are options and settings which can only be changed by an admin but there is no button to push or file menu option to become root.

So how does one change those options? The only solution I see is to log out and attmpt to log in as root. Hmmm.... When will this be fixed or Maybe it works for others and my build is somehow incomplete? Anyone have solutions?

Someone else will have to answer for a 4.5 version, but on my 4.4.4 KDE version on Kubuntu 10.04 I can go to the settings for Time and Date, do some changes. The "Apply" button is a little different from the others. It has a key symbol on it signifying that if I click on it, I will have to give my password to be able to save the changes.

Is it possible to just click on the apply button? Or is it greyed out?

I assume you are using Debian as base? I am using Kubuntu and I have never seen any specific button to become root. But for some settings, I get asked for my password, and if the logged in user do not have sudo permission, it will not work.

One of the actions where this is used is installation of new programs.

But as I said, others will have to answer for v. 4.5

Note that if you compile from trunk, and do not install with a prefix of /usr or copy the needed files over, then PolicyKit will not work ( and therefore what Oceanwatcher describes won't work )

Just wondering how most users are doing it. Does the system-settings/networking graphical interface have an option to log in or make/save changes with root privileges? As I said, I'm still building kdenetworking, but so far I don't see it.... and bcooksey, I am installing my trunk version of kde4.5 into "/home/kde-devel/kde/trunk" which is how the intructions on the kde website tell one how to do it.

Without the administrator option I don't see how a typical home user can administrate their network connections without logging out of their session and logging back in as root; which is nearly impossible using most log in managers.

If there isn't such an option I find that odd to say the least considering that we are 2.5 years into the "kde4" build.

Normally, KDE is installed and configured by a distributor, who is responsible for ensuring that the needed PolicyKit components are installed correctly.

In the case of users who build from Trunk, it is assumed you don't want to contaminate your existing system installations, so infrastructure that needs hooks which depend on root access won't work. It is assumed as a user building trunk that you will move the files into the needed positions.

I use this script to copy the security files where they can be read:
sudo cp -r /home/kde/KDE/etc/dbus-1/ /etc/
sudo cp -r /home/kde/KDE/share/dbus-1/ /usr/share/
sudo cp -r /home/kde/KDE/share/PolicyKit/ /usr/share/

Change the base KDE dir as needed. The PolicyKit directory may differ depending on your PK incompatibility version (I use the oldest).

bcooksley wrote:Normally, KDE is installed and configured by a distributor, who is responsible for ensuring that the needed PolicyKit components are installed correctly.

In the case of users who build from Trunk, it is assumed you don't want to contaminate your existing system installations, so infrastructure that needs hooks which depend on root access won't work. It is assumed as a user building trunk that you will move the files into the needed positions.

Not sure I follow you here. I am installing from a Debian distribution. I get what you mean about distributors having all the dependencies listed and tied to the file to be installed... in this case "kdenetworking," but building from trunk with cmakekde goes through a configure script and shows me what required & optional components are found/not found so I can go back to my repository list and install the needed programs.

bcooksley, maybe I'm not getting completely what you are meaning. I don't see why my installation wouldn't build a certain program with an admin login button when the program called for it as long as I have the dependent programs installed properly. I'm not sure what you mean by "hooks?" in this example.

In order for administration mode to function, KDE uses helper programs, which are installed alongside D-Bus and PolicyKit files. The D-Bus files instruct the system wide bus to launch the helper if it is called.

When launched, the helper checks using PolicyKit if the user is authorized to perform the action. If PolicyKit cannot find the appropriate files, then it will refuse authorization to protect the system's security.

As a result, if all three components are not installed correctly, administration mode simply won't work. In the case of installing it in to your $HOME directory, neither PolicyKit or the system wide bus are able to find the needed files, preventing it from functioning.

bcooksley wrote:In order for administration mode to function, KDE uses helper programs, which are installed alongside D-Bus and PolicyKit files. The D-Bus files instruct the system wide bus to launch the helper if it is called.

When launched, the helper checks using PolicyKit if the user is authorized to perform the action. If PolicyKit cannot find the appropriate files, then it will refuse authorization to protect the system's security.

As a result, if all three components are not installed correctly, administration mode simply won't work. In the case of installing it in to your $HOME directory, neither PolicyKit or the system wide bus are able to find the needed files, preventing it from functioning.

Sure that makes sense, but shouldn't the gui still provide the administrator log in button, it would just be grayed out as a non-usuable option to the non-root user?

Also, the build directions on the techbase website suggest that you create a user called kde-devel and then build the kde/trunk version within that user directory. cmakekde installs everything under this directory too. is this no longer the preferred method of building kde? If not, what is, and why is the techbase page not corrected?

That is the preferred method if you are a developer, where you don't want to install files that a package manager should manage in system areas.

The Administrator Login button is part of Apply. If Administrator privileges can be granted, then a key icon will be shown instead of a tick, and you will be prompted for the appropriate password when you press apply. If you don't have the ability to be granted privileges, then the apply button will be greyed out.

bcooksley wrote:That is the preferred method if you are a developer, where you don't want to install files that a package manager should manage in system areas.

The Administrator Login button is part of Apply. If Administrator privileges can be granted, then a key icon will be shown instead of a tick, and you will be prompted for the appropriate password when you press apply. If you don't have the ability to be granted privileges, then the apply button will be greyed out.

Ok... so that I understand you... In the KDE4 series there will be no "admin" buttons, but when admin privileges are required a pop-up will prompt the user for the admin password? This makes good sense to me.

The other part of your response eludes me. You agreed that installing a KDE developer build is best done from by creating a user called kde-devel and building from that home directory. but then previously you stated that if built in that directory that polkit and other files needed to allow admin privileges may not find appropriate files needed to allow admin login?

So, if that is true I don't see how both of your statements can be correct. Please clarify, and thanks in advance!

In general, KDE Developers do not need the Administration mode functions as they have either performed the setup already, or know / can find out easily / are not afraid of making the changes needed to get what is needed done.

As a result, having this functionality not work is not detrimental to them using a development version of KDE.