Bug 151669

*** Bug 153467 has been marked as a duplicate of this bug. ***

I can confirm this is still the behavior on 3.96.3

Same behavior for trunk checkout as of 02/9/2008

This bug is over 3 months old and the status is still new?

Does it need to be reported against a newer KDE source?

I reported as a bug under Fedora 9:
https://bugzilla.redhat.com/show_bug.cgi?id=434824

I still see no possibility to switch to administrator mode in KDE 4.0.1, for example in the login manager module.

Same issue from most recent svn.

If this is intended behavior, maybe remove the sections from view that a normal user would not have access to.

Also, adding a menu to open system settings as root might be nice (like we have for konqueror.)  I know it is easy to launch it from the command line, but this would make it more accesible to people not smart enough to launch it themselves (especially since when you switch to root user no kde apps open.)

*** Bug 161102 has been marked as a duplicate of this bug. ***

"I know it is easy to launch it from the command line" - depends on your system setup. i used alt+f2 on kde3 to run as root, but kde4 doesnt offer this and there is no kdesu

*** Bug 163901 has been marked as a duplicate of this bug. ***

This bug is still present in KDE 4.0.5.
There could be a workaround, namely "/usr/lib/kde4/lib/kde4/libexec/kdesu /usr/lib/kde4/bin/systemsettings" but, at least in KUbuntu 8.04 it doesn't work as it locks the application.
I would say it is a major, show stopper bug.

 I use "sudo" to run "/usr/lib/kde4/bin/systemsettings" from the shell.  But that's a work-around not a fix.  I'd agree that not being able to enter administrator mode for system settings is a show-stopper.

Still present in Kubuntu 8.04 KDE 4 Beta 2.
Okay, it's easy to open a terminal and type »sudo /usr/lib/kde4/bin/systemsettings«, but inexpierienced users will go crazy!

Please assign that bug to someone so that it will be fixed soon...

*** Bug 165124 has been marked as a duplicate of this bug. ***

*** Bug 165411 has been marked as a duplicate of this bug. ***

*** Bug 165679 has been marked as a duplicate of this bug. ***

Still valid for KDE 4.1 RC1

Apart from the missing proxy support, this is one of the most critical flaws in KDE4. I don't know much about the KDE4 source code, but I expect this should be really easy to fix.

Unfortunately, I'm not a C++ programmer (but I'm learning atm^^) and this bug is really annoying, so can someone PLEASE fix this?

There's this hack courtesy of Lukáš Tinkl:
http://cvs.fedoraproject.org/viewcvs/rpms/kdebase-workspace/devel/kdebase-workspace-4.0.72-rootprivs.patch?rev=1.1&view=markup

plus the clock.desktop fix which goes with it:
http://cvs.fedoraproject.org/viewcvs/rpms/kdebase-workspace/devel/kdebase-workspace-4.0.3-timedate-kcm.patch?rev=1.1&view=markup

but we don't expect this hack to be included upstream (that's why we haven't submitted it). Still, I'm mentioning it here in case it helps some people.

*** Bug 167366 has been marked as a duplicate of this bug. ***

In my opinion the best solution is integrating kde4 with policykit for getting administrator privilages.

There is no 4.1.1 for this component, so setting it to 4.1.

(In reply to comment #22)
> There is no 4.1.1 for this component, so setting it to 4.1.

"Version" means "which version was the bug/wish reported against.

I was under the impression that the version should be bumped to the most current version an issue has been confirmed for to prevent bug rot. Sorry.

Date & Time has now an administrator mode possible. You are prompted for root password for applying the changes. This is trunk, pre 4.2.

I have found this in 4.1.2 and I don't think it has been disabled deliberately.

It is simply not done, not disabled, I fear. I looked at Kubuntu screenshots when I wrote that it was there in earlier versions and I did not know that this is a complete rewrite, not a port of the Kubuntu version.

Confirmed for KDE 4.1.2 on Gentoo

I have noticed that this bug has been reported for almost 1 year now. Will it be fixed for the 4.2 release? That would be great because right now I am forced to use KDM 3 just because of the lack of an administrator mode.
I would like to go all KDE 4 by next release - no patch work ;)

Man, I really hope someone gets to this soon... it's pretty important..

Im using KDE 4.2 betas from Mandriva cooker repo's. Bug still exists. The help says to click the "Modify" button and you will be prompted for a password, but there is no modify button. This is really very irritating, and it doesn't seem like it would be all that difficult for someone to fix this.

(In reply to comment #31)
I have the same experience with KDE 4.2 betas on openSUSE 11.1. But what can you expect from bugs with "new" status ;?)

See KDE 4.2 Feature Plan:
http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan

TODO 	 System Settings 	 add Administrator mode button. See Bug 151669 	 Alessandro Diaferia <alediaferia@gmail.com>

It's simply not done yet. Maybe fixed before 4.2, but I doubt it. Probably one or two versions later. The status "new" here is wrong - should be assigned to Alessandro.

Very annoying bug though.

The newest KDE Commit Digest at http://commit-digest.org/issues/2009-01-04/ features "PolicyKit" for Administrator Mode in Applications. It says there will be a library for PolicyKit in 4.3, so I doubt that this bug will be fixed in 4.2.

Well, KDE 4.2 is past Hard Feature Freeze (that's why I added "see Bug 151669" to the feature plan). I still think I would be good if fedora submitted their patch as an interim fix until PolicyKit is integrated, or even if KDE enabled a patch that used PolicyKit if it were found (I've installed the policykit library from playground, and anyone else who is affected could do the same)

Using unstable/beta/playground software for security related things is a bit hazardous, isn't it?

PolicyKit itself is fully stable, and is used in fedora. I only compiled the KDE frontend, and even that is from kdereview, not playfround (sorry, I made a mistake before)

Probably soe day in a 4.2.x release. If Lukas is working on this I'm sure he'll try to get it finished soon - at least that's as I know him ;-).

It's resolved in KDE 4.2 by using kdesu, can we close this bug now?

I would say yes. It works for me in openSUSE. Is it now distribution-independent?

Fixed ?
I can't change anything in systemsettings Login Manager or Samba because all is greyed out. There is still no Admin Button.

ArchLinux 686
kdebase 4.2.0-1
qt 4.4.3-5

If I understood correctly (I installed 4.1.96 & now 4.2 but did not have time to test), it is now possible to start systemsettings via kdesu, thus you can edit stuff as normal user.

If this is the case, I would say the issue needs to stay open until the 2.x/3.x admin button is implemented, as well. The use of kdesu is non-obvious for the average user.

@Richard Hartmann:
No, (at least in some distributions, I don't know if it works everywhere) if you run Systemsettings as normal user, and you click on the icon of a module which needs administrative privileges, it asks for the root password and opens the module as root. It is user-frendly. It is slightly different (and thus questionnable from a usability perspective) because it opens the module in a new window, not inside Systemsettings.

nope, its not like that here (Arch Linux, kdemod 4.2)

Openening in a new window is Bad, imo.

There is neither a password question nor a Administrator Mode Button (as stated in the help) here on ArchLinux with KDE 4.2.0 (not mod).

Neither on Gentoo

There nothing like that on Mandriva

The current state is a regression. There is an admin button in KDE 3.5 and before. systemsettings in KDE 4.x should have one too.

So as it I see from comments, it's openSUSE's specific workaround and not a upstream change. And AFAIR there was not working Administrator Mode button some time ago in 4.x so I think developers are working on it.

Actually, it's been a bit since I checked, but I seem to remember being able to run systemsettings as root in Kubuntu.

However, whenever I did, Samba settings would never be there, so it was pretty useless to me in that regard. It helped me do some other stuff, though.

I'd really just like the admin mode button back. It made everything so simple. As it is now, there's no way to edit Samba settings in KDE4 via the GUI.

(In reply to comment #38)
> Probably soe day in a 4.2.x release. If Lukas is working on this I'm sure he'll
> try to get it finished soon - at least that's as I know him ;-).
> 

Well actually, Lukas only created the workaround patch. This seems to be destined to become a permanent problem

KDE 4.2.0, kernel 2.6.24-gentoo-r3, architecture: amd64
I have no switch button (to get to root mode) in systemsettings. Furthermore
# systemsettings
does not work - no window appears. 
"$ sudo systemsettings" or "$ kdesu systemsettings" works.
It would be great if there is admin button back or if # systemsettings works as it is possible in KDE 3.5.x

KDE 4.2.0, kernel 2.6.24-gentoo-r3, architecture: amd64
I have no switch button (to get to root mode) in systemsettings. Furthermore
# systemsettings
does not work - no window appears. 
"$ sudo systemsettings" or "$ kdesu systemsettings" works.
It would be great if there is admin button back or if # systemsettings works as it is possible in KDE 3.5.x

*** Bug 187207 has been marked as a duplicate of this bug. ***

sudo systemsettings

Re: Comment #55. Thanks for that. I'll keep the snarky remarks to myself. It does deserve this though: That isn't a fix for this bug. It is a work-around. Systemsettings can and *should* have a simple admin mode button. I'm perfectly comfortable with a command line, but if there is an elegant way to not deal with the cli, I'm not going to. I say to myself "would I rather click on konsole, then type sudo whatever... or would I rather click an icon, and then click another admin mode button? Hmm.."

-_- I can also do su -c vim /home/user/.kde4/share/config....
Do you call it usable?

*** Bug 189855 has been marked as a duplicate of this bug. ***

Wasn't there according to the feature plan of KDE 4.2 to be implemented an administrator button?

http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan

This is still listed as "to do" and there are a bunch of other things that are listed "to do" or "in progress" are these things then going into KDE 4.3? I looked also at the feature plan for 4.3 and I can't any of the missing features from 4.2 in 4.3. So what will happen to those things? Because 4.2.2 was the last of the 4.2 series, right, before 4.3?

> So what will happen to those things?

According to Dario Freddi the plan is to have these changes in 4.4:
http://drfav.wordpress.com/2009/04/07/a-bunch-of-quick-updates/
«Polkit-qt is shaping up nicely. The bad news is that all the announced support for root controls in systemsettings will be delayed to 4.4. The good news is that you will get much more than what I already talked about. I can’t unveil details right now for obvious reasons but you should see that in the very near future. Again, I will probably write a whole post about that when it’s time.»

> Because 4.2.2 was the last of the 4.2 series, right, before 4.3?

Of course not, but this is not the right place to discuss about these things, please use the forum for these kind of questions:
http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule

Some distros (including openSUSE) have already solved/worked around the problem in a not optimal but working way. I think something like that should be added to default KDE until the better solution can be used. Simple users (who have no idea about command line) do not need sophisticated features but they _need_ a way to change administrator settings.

*** Bug 189902 has been marked as a duplicate of this bug. ***

*** Bug 192719 has been marked as a duplicate of this bug. ***

I am using Mandriva Linux 2009.1 (Spring) final release, and there is still no administrative functionality. Mandriva has discontinued the default inclusion of KDE3 with their installation, so a new user will no longer even be aware that KDE3 could be an option . . .

This bug report was opened November 1, 2007. This is May 24, 2009 (a year and a half later). The status of this bug is still NEW (with NORmal priority) and no one seems to have any idea when (or if) there will ever be a resolution (only vague assurances that we will see even more than we have requested . . .). Assurances are of no value unless they are backed up with some form of firm limitation as th when they will be met, and KDE-4.4.x is too far out to constitute such a commitment. 

I have resorted to editing the menu to add a "Systemsettings Admin" menu item that lets me run system settings as root, but this is still a poor work around for a new user who is not familiar with Linux (or KDE). If adding advancements to a Desktop Environment obfuscates its functionality, I have to ask if the Desktop Environment has advanced (or regressed)?

Based on the evidence I see in this bug report, the ability of a novice user to administer the system is not a high priority, or at least not as important as it should be.

Please understand that my intention is not to offend any one. If I have, I sincerely apologize. I simply request that the development team give this issue a higher priority because it negatively impacts new users (and their impression of KDE).

some bug is awfol long time to fix. They must be hard to solve

Actually openSUSE has practically solved it (even if it is more a workaround), just KDE devs don't bother to temporarely integrate it. Other distros should use the openSUSE patch.

Btw I don't know but I doubt that the old KControl solution would be so damn hard to do, they just want to wait for one more framework to have some extra features that no one needs.

(In reply to comment #65)
> some bug is awfol long time to fix. They must be hard to solve
Yeh, that's an awfully awful time-consuming huge mega bug ;P common...

(In reply to comment #66)
There was a workaround in openSUSE, but it's gone in 4.3beta (dunno why).

(In reply to comment #64)
Maybe it would help thing a bit if we start to complain to the distros,
especially those that want to be considered "easy to use" (like e.g. kubuntu,
mandriva, etc...) and they will help KDE people to solve it.

It's ridiculously old bug with very little attention from the devs. I
understand that some things are not so easy to fix and all that, but common
over a year?! 

Some status update would be nice, is it assigned to anyone? Was works started?
Or just mark it "DONT_CARE/GTFO" :F

> Some status update would be nice, is it assigned to anyone? Was works started?
> Or just mark it "DONT_CARE/GTFO" :F

Fully agree. Please pronounce "We don't care about this report with 1751 votes, we want fucken bells and whistles. We don't care about users" and mark a bug WONTFIX.

Sorry, but we don't need it in KDE 4._current+2_, we need it NOW.

Guys guys. First of all, for fixing this bug there was a own library developed "qPolicyKit" / "kPolicyKit", and there have been several blogs about the project status. As far as I know this is finished. As far as I know, they're not far from fixing this one, and yes, it consumed time.

It's still a open source project. Allthough, this is something which should have been covered with 4.0. Anyway, there are workarounds for this (sudo systemsettings), and policykit wasn't in a really usable state when KDE4 was released.

Please, show a bit patience. The guys are not paid to work on this features, and just because you don't see the work does not mean it's not being worked on. They are, and the KDE guys are doing a great job - also on this, even when it takes a bit longer this time.

Well, KControl had administrator mode without PolicyKit.

And kControl is not SystemSettings, as simple as it is.

I thought it was obvious that I meant that it could been done without polkit, so it could've been done without polkit also in Systemsettings.

>Well, KControl had administrator mode without PolicyKit.

Well, in Kubuntu I have administrator mode in System Settings without PolicyKit too.

(In reply to comment #69)
> Guys guys. First of all, for fixing this bug there was a own library developed
> "qPolicyKit" / "kPolicyKit", and there have been several blogs about the
> project status. As far as I know this is finished. As far as I know, they're
> not far from fixing this one, and yes, it consumed time.
> 
> It's still a open source project. Allthough, this is something which should
> have been covered with 4.0. Anyway, there are workarounds for this (sudo
> systemsettings), and policykit wasn't in a really usable state when KDE4 was
> released.

Than why this bug's status is NEW? not WORKINPROGRESS/ASSIGNED or whatever
 
> Please, show a bit patience. The guys are not paid to work on this features,
> and just because you don't see the work does not mean it's not being worked on.

Please take into account that people are (were) patient for over a year now. :|

> They are, and the KDE guys are doing a great job - also on this, even when it
> takes a bit longer this time.

No one is questioning that KDE devs are doing great job (we wouldn't use it if that would be the case ;P), but they are not so good at informing people about this bug's status, which pisses off a lots of people (see the CC list, it's really long and +1700 votes... and thats only people who care enough to report bugs), I think they deserve a simple "it's OK people, we're working on it, it will be in 4.3.x". Can someone please at least change bug status, it's 5 seconds to do it :)

> I think they deserve a simple "it's OK people, we're working on it, it
> will be in 4.3.x".

You mean they deserve a lie?

I get today around 10 messages from this report, all of them fruitless. Instead of writing long memos about changing the status (the status is NEW and it won't be confirmed any any further), do it yourself. Go ahead, grab the code, and do it. Everybody will be grateful.

There are tons of issues on BKO, there are tons of issues in ML, complaining "look at _this_ report, is important" does not any good. Understand the simple fact, that number of developers is by several orders of magnitude smaller than number of reports! Do the math -- thank you in advance.

First of all, this task hasn't been assigned to any special person. As far as I know, there are more than 3 people working on this. It is split into several, completely different tasks (first of all the implementation of policykit, which was finished, and merged by drf as I know. Secondly, the implementation of this into kdeadmin .. not sure if there's anybody who feels he can do this alone, since kdeadmin has a lot of parts, where different people are responsible for).

From what I've read, the implementations of kcontrol, the patches of opensuse, kubuntu etc. are pure hacks. Nothing more or less.

Now, as the speaker before said. Grab the code, make it happen faster. In cases like this, I experienced that the guys will be faster than yourself, except if you're coming with a vast knowledge about all this.

About grepping the code and do it ourself: What about the "huge" amount of useers there do not know to code?

(In reply to comment #75)
> > I think they deserve a simple "it's OK people, we're working on it, it
> > will be in 4.3.x".
> 
> You mean they deserve a lie?

(In reply to comment #76)
> First of all, this task hasn't been assigned to any special person. As far as I
> know, there are more than 3 people working on this. It is split into several,
> completely different tasks (first of all the implementation of policykit, which
> was finished, and merged by drf as I know. Secondly, the implementation of this
> into kdeadmin .. not sure if there's anybody who feels he can do this alone,
> since kdeadmin has a lot of parts, where different people are responsible for).

Now I'm confused about the status, are they working on it or not? ;)

> From what I've read, the implementations of kcontrol, the patches of opensuse,
> kubuntu etc. are pure hacks. Nothing more or less.

It's obvious they are hacks, but isn't it all the regular user needs until the devs get the implementation to the perfection? ;) Whats wrong in having WORKING temporary hack, instead of non working admin panel?

> Now, as the speaker before said. Grab the code, make it happen faster. 
> In cases like this, I experienced that the guys will be faster than yourself, > except if you're coming with a vast knowledge about all this.

I'd love to if I only had more time. There's no point in being offensive, all I wrote was the truth, there is confusion in community about this issue and it needs to be sorted out thats all. If you would read my comments carefully you would see that all I'm saying is that people wants to know whats going on with this feature and when it will be ready, is that so rude to ask why +1 year old bug report has NEW status? Doesn't +1700 votes not count for CONFIRMED? You say that 3 people are working on it, thats great news, but why this bug report don't reflect this? Simple questions, thats all.

First of all, assigning the task to one person when multiple persons work on it is pointless, and yes, it's being worked on. Yes, it should and could be confirmed, but I'm not sure if you need to assign somebody if you confirm it (i'm not a kde dev, just following closely spending some time on patches).

What ever the tracker says, but looking a bit closer, it's in the 4.2 features list (!), even referring to this bug ID. There is a contact person assigned there (Alessandro Diaferia).
Following the path down, you can see that the qPolicyKit integration is done, and the kPolicyKit integration is in progress - what will be the base of the admin mode. Allthough, I doubt it will be done in 4.2 still (4.2.4?).

Secondly, probably more important for a personal reason, it wasn't meant in an offensive way what I wrote, and I'm sorry if it seemed offensive. But it's what I experienced, working on the same thing in a schedule "against" persons who do this for a way longer than I is most likely a lost situation. That's why I wrote "I experienced".
You personally say you're short of time. There are plenty others complaining about this bug, and I understand (as I don't bring the skills myself - I think, never looked at it though since I know that it's being worked on) that some of them do not have the skills to help.
But as you can expect, you're not the only person short of time, also the developers, since most are not paid for their work on KDE, are also busy with their lifes and jobs.
Some of the KDE devs are powered by Novell, who originally wrote the patch for the administrator mode in KDE 4. I think there are reasons why it got refused to get into the KDE mainstream code.

The reason plain and simple why KControl supported "Administrator Mode" was because it implemented a hack which used KDESu to run the module as root then performed an XEmbed into its own window. It didn't work consistently either.

This method was not possible in KDE 4 because it is multi platform and XEmbed is only possible on X server based systems.

Not to mention it is a bad idea to run graphical applications as root anyway.
This feature must be implemented using a PolicyKit type system in the modules individually ( or the external apps feature being added to 4.4 being abused )

(In reply to comment #79)
> What ever the tracker says, but looking a bit closer, it's in the 4.2 features
> list (!), even referring to this bug ID. 
Yes, that's what I've remembered that this bug was suppose to be fixed in 4.2.

> Following the path down, you can see that the qPolicyKit integration is done,
> and the kPolicyKit integration is in progress - what will be the base of the
> admin mode. Allthough, I doubt it will be done in 4.2 still (4.2.4?).
So it seams that resolution is closer to the end.

> But as you can expect, you're not the only person short of time, also the
> developers, since most are not paid for their work on KDE, are also busy with
> their lifes and jobs.
Yes, I fully understand that and I'm grateful for their time and effort.

Enough talking, it's time to find and patch some bugs ;)

You should realize that not every development project in kde uses "assigned". This bug has several developers on the cc:, it has *blog* entries of people talking about working on it per comment #69, so obviously people know about it and are working on it: what more do you want? If you want to just complain somewhere, don't do it on this report, it is for *bugs*. Trashing the developers working on it is not motivating. If you would like to help KDE but can't code, you can always do: bug triage (with bugsquad), documentation, artwork, translation, promotion/demos/talks and marketing (help us get more coders/etc), usability, accessibility(!!!), etc., etc. 


Furthermore, what individual distros do or don't do doesn't matter here, this is upstream KDE. So confirming anything here, that is *not* a pure trunk build is pointless. And no, it isn't implemented yet.

He just wants the bug to be confirmed, not assigned. And i agree with him.

> He just wants the bug to be confirmed, not assigned. And i agree with him.

Bug status is NEW, which already means "confirmed".

#82: what individual distros have does matter because if they have a working workaround (as openSUSE has), it could be taken temporarily by upstream KDE until a better solution is made.

(In reply to comment #82)
> You should realize that not every development project in kde uses "assigned".
> This bug has several developers on the cc:, it has *blog* entries of people
> talking about working on it per comment #69, so obviously people know about it
> and are working on it: what more do you want? If you want to just complain
> somewhere, don't do it on this report, it is for *bugs*. Trashing the
> developers working on it is not motivating. 

I confused NEW with UNCONFIRMED (surely I need more sleep ;)
NEW == CONFIRMED I get it :)

Nobody's trashing anyone, it's just a matter of communication, I know that day have only 24h and most of them are already taken by work/sleep/life and there is always not enough time :|

Please note that this discussion would never happen if there was some feedback in this report about status, to ensure people that the solution is being work upon, it takes only a minute to do it.

OK, maybe I overreacted, shit happens, but now at least we know whats the status and thats important IMHO, because healthy community is about communication and feedback.

> If you would like to help KDE but
> can't code, you can always do: bug triage (with bugsquad), documentation,
> artwork, translation, promotion/demos/talks and marketing (help us get more
> coders/etc), usability, accessibility(!!!), etc., etc. 

For that matter, I regularly fill bug reports, test factory repo, and if I have enough time I fix bugs and send patches, and I encourage everyone to do the same. :) 

Now, I think everybody are happy ;)

The schedules, http://techbase.kde.org/Schedules/KDE4/4.3_Feature_Plan#kdebase-workspace.

IN PROGRESS 	KControl4 	Import refactor of systemsettings with Tree and Icon view support

So if this feature was a kcontrol feature, would it not make perfect sense that it will be worked into kcontrol4, without any need to sulk or stamp feet.

(In reply to comment #85)
I agree with you that it could make sense, but in this particular case it does not make sense. As Ben wrote in comment #80, KDE is cross platform, using X-Server specific patches isn't a solution in any case (probably wouldn't even compile on windows).

I completely agree with comment #82, discussions like this should not be held here but on the mailing lists.

Just to add here... the commit digest 2009-01-04
http://commit-digest.org/issues/2009-01-04/
That's where I read something about this the first time, and the devs actively called for help on this.

Users not need the administrative modules on Windows/OS X because they use the OS's administration tools. (And KDE 4.3 for those platforms, unlike for X11, still won't be supposed to be ready for typical desktop users, will it?)

Btw (currently) policykit is also only for Unix-like systems, isn't it?

@Comment #87: KControl4 was merged in as System Settings shortly before the hard feature freeze. The KControl reference was simply because it supported the Tree View. No hack will be added.

- System Settings Maintainer

*** Bug 194216 has been marked as a duplicate of this bug. ***

Ben, please for the benefit of the many, either mark this report as WONTFIX or enlighten us with some clarity. :)
All code is considered some sort of "Hack" In the view (Of many) Of the hackers that make up foss, so either yes, we know, it's on it's way or sorry guys, it's not happening?

My personal view is not fussed and indifferent, however there are obviously others wasting their time reporting it here and they seem unhappy about it.
So, do you think it will be possible for you to add this kde3 feature to kde4?

This feature will be implemented using PolicyKit, which means user interfaces do not have to run as root, and Administrators will have greater power over allowing users to manage their systems.

Unfortunately, due to time constraints, this will not be implemented in KDE 4.3. It requires changes to all modules that need Administrator mode support.
No time frame is available at this stage.

Ben, will it be backported to 4.3 when it will be done?

It will likely involve string changes, or the changes will be too invasive to backport. It will not be known if it is backportable until it is actually done.

*** Bug 194519 has been marked as a duplicate of this bug. ***

Same problem here
Mandriva 2009.1
   KDE 4.2.2
ArchLinux
   KDEmod

I must be going blind, how do I vote on this thing....

#98 at the top of the bugreport there is a blue box. At the button of it there is a link where you can vote

Thanks.
Yeah it wasn't there til I commented and thus become subscribed. That was tougher than it should have been.

In the latest Kubuntu release policykit seems to be integrated in the systemsettings. There is no need to enter the root password anymore. Is this still a hacky approach?

4.2.96 and still not working...

@Everyone: This bug will be updated when progress is made. In 4.4 a authentication framework, written by a GSOC student will hopefully be imported allowing progress.

*** Bug 201421 has been marked as a duplicate of this bug. ***

as policykit-kde is now available in kde-4.3 I wonder why another authentication framework needs to be implemented for kde 4.4...

@comment #105:
For example PolicyKit doesn't exist in all platforms KDE supports.
Read more here:
http://socghop.appspot.com/student_project/show/google/gsoc2009/kde/t124022559993
http://www.gigabytes.it/2009/07/kde-authorization-library-first-step/
http://www.gigabytes.it/2009/07/kde-authorization-library-second-step/

And here:
http://www.gigabytes.it/2009/08/kde-authorization-library-final-step/
"As part of my work I’ve ported the date/time kcm module to the new library. Its code already followed the caller/helper pattern, but authorization used kdesu and data was passed using commandline arguments. The new code saves some lines of code and seems a bit cleaner."

Why this EPIC bug hasn't even been assigned???????

Probably because it depends on the work of several developers, I think.
However it's sort of fixed:
http://drfav.wordpress.com/2009/08/31/tokamak-kauth-into-kdelibs/

it's fixed in opensuse.

@Evgeny: Why this EPIC bug hasn't even been assigned???????

As I recall Admin Mode was scheduled to be added in KDE4.3...the deadline flew by and it did not get done...last I heard it was on the To-Do list for KDE4.4

@Dave Plater

Odds *buntu and OpenSUSE made their own patch because they got impatient with no progress on the matter.

With the KAuth framework, System Settings is actually now equipped for "Administrator mode" all that is needed is appropriate support added to the KControl modules that need it. Therefore this bug is "fixed" in a sense.

@mb1: Yes openSUSE / Kubuntu are including are Root mode hack in System Settings, which will hopefully be removed with KDE 4.4.

Arch Linux's KDEMod (Chakra) also has a root dialogue appear whenever you go into root areas like Samba.

That's good enough for me for now.

@Holly

Ah, so THAT is one of the patches the Chakra guys put on Vanilla KDE on Arch. We wonder sometimes just where they do patch things :>)


It ain't there on Vanilla KDE on Arch tho' of course.

Yeah, I didn't think it would be.

I'm pretty sure the other patches just make it run faster. The website might have a list of the optimizations or something. I've not used vanilla KDE in Arch so I dunno the differences in performance.

For me, it isn't a big performance difference, if any (Arch Kdemod).


But the fact is, that after update to KDE 4.3.1, I am prompted for root password when I try to open Login screen settings from KCM, and that's just what I wanted (In 4.3, all options were simply greyed out, and no root prompt)

Administrator mode has been implemented in trunk. It will be available in KDE 4.4 and it will not be backported to 4.3.

Thanks to Dario F. for the development :-)

*** Bug 218381 has been marked as a duplicate of this bug. ***

*** Bug 218381 has been marked as a duplicate of this bug. ***

*** Bug 219818 has been marked as a duplicate of this bug. ***

One year later, I don't see any admin mode :x
I am using Mandriva's binary (KDE 4.4 RC3).

As stated previously, System Settings will ask for elevated privilages only when needed and no longer has an explicit button to elevate privilages.

> --- Comment #122 from Ben Cooksley <sourtooth gmail com>  2010-02-05 09:50:18 ---
> As stated previously, System Settings will ask for elevated privilages only
> when needed and no longer has an explicit button to elevate privilages.

I don't see it. I just tried yesterday on the current Mandriva Cooker
and all the KDM settings are all grayed out still with seemingly no
way to edit them. Is there something I'm missing?

This is either because the KDM control module hasn't been ported to KAuth yet or due to a bug in your PolicyKit configuration.

I just tested in on Kubuntu 4.4 RC2. It seems ok to me there. Everywhere where it is needed, I am asked for the password. If it does not work on Mandriva, you need to report it to their bug tracker.

Am Freitag 05 Februar 2010 08:59:24 schrieb Rémi:
> https://bugs.kde.org/show_bug.cgi?id=151669
> 
> 
> 
> 
> 
> --- Comment #121 from Rémi <remi assailly free fr>  2010-02-05 08:59:15 ---
> One year later, I don't see any admin mode :x
> I am using Mandriva's binary (KDE 4.4 RC3).
> 
Works fine on openSuse 11.2 with the stable version, but I haven't had any luck 
with 4.4 either. I guess it will be back in the final version though.

(In reply to comment #122)
> As stated previously, System Settings will ask for elevated privilages only
> when needed and no longer has an explicit button to elevate privilages.

I cannot see that either! 

Version:           1.12.4 (using 4.3.4 (KDE 4.3.4), Debian packages)
Compiler:          cc
OS:                Linux (x86_64) release 2.6.30-2-amd64

So why is this "fixed"?

Martin

(In reply to comment #124)
> This is either because the KDM control module hasn't been ported to KAuth yet
> or due to a bug in your PolicyKit configuration.

Ok, Ben, is this a workround or do you tell us the solution. Sorry, this shall not sound unfriendly but this bug is quite awful, because a lot of us out there will not know how to configure some settings without a solution for this bug! This is  bit like throwing away the key for the car trunk and telling the driver: "Sorry but this is open source!" ;-) And we all know that this has  interdependences with the use of "sudo", "sux", etc.

My question on the PolicyKit configuration: Can you give us a hint which screw to turn (in Germany we say so: "an welcher Schrube wir drehen sollen") around here? 

Thank you for your help!  Martin

The Bug itself, regarding System Settings having no way to run commands that needed elevated privilages is fixed by KAuth.

KAuth has no visual signs of its presence other than "Apply" having a lock icon if you need to authenticate.

Any issues you are having with the KDM control module and its inability to gain privilages is a seperate bug with it.

Unfortunately I don't know much about PolicyKit itself, however the Clock KCM is known to work. If it doesn't, please file a bug report with your distribution.

As an alternative, run kdesu kcmshell4 kdm

> I cannot see that either! 

> Version:           1.12.4 (using 4.3.4 (KDE 4.3.4), Debian packages)
> So why is this "fixed"?

Fixed in 4.4. Wait for it few days:)

(In reply to comment #130)
> > I cannot see that either! 
> 
> > Version:           1.12.4 (using 4.3.4 (KDE 4.3.4), Debian packages)
> > So why is this "fixed"?
> 
> Fixed in 4.4. Wait for it few days:)

What does "a few days" mean! ;-) Martin

Four.

http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule#February_9th.2C_2010:_Release_KDE_SC_4.4

Hi Ben!
(In reply to comment #129)
> The Bug itself, regarding System Settings having no way to run commands that
> needed elevated privilages is fixed by KAuth.
> 
> KAuth has no visual signs of its presence other than "Apply" having a lock icon
> if you need to authenticate.
> 
> Any issues you are having with the KDM control module and its inability to gain
> privilages is a seperate bug with it.
> 
> Unfortunately I don't know much about PolicyKit itself, however the Clock KCM
> is known to work. 

What is "Clock KCM"?

> If it doesn't, please file a bug report with your
> distribution.
> 
> As an alternative, run kdesu kcmshell4 kdm

Yes, this works! But this is only one example "kdm". How do I know which other
elements to start?

Thank you again! Martin

> As stated previously, System Settings will ask for elevated privilages only when needed and no longer has an explicit button to elevate privilages.

How can I be asked for elevated privilages if I am unable to change anything ?
;)

Tools for SAMBA or KDM have been read only since KDE 4.0. But is still the
same, unfixed...

> Works fine on openSuse 11.2 with the stable version, but I haven't had any luck with 4.4 either. I guess it will be back in the final version though.

Working on opensuse does not seem working upstream ;)
Bug 180437 is a good example, works very well on mandriva cooker, do not seem to be fixed upstream :)

Am Freitag 05 Februar 2010 13:38:34 schrieb Rémi:
> https://bugs.kde.org/show_bug.cgi?id=151669
> 
> 
> 
> 
> 
> --- Comment #134 from Rémi <remi assailly free fr>  2010-02-05 13:38:27 ---
> 
> > As stated previously, System Settings will ask for elevated privilages
> > only when needed and no longer has an explicit button to elevate
> > privilages.
> 
> How can I be asked for elevated privilages if I am unable to change
>  anything ? ;)
> 
> Tools for SAMBA or KDM have been read only since KDE 4.0. But is still the
> same, unfixed...
> 
> > Works fine on openSuse 11.2 with the stable version, but I haven't had
> > any luck with 4.4 either. I guess it will be back in the final version
> > though.
> 
> Working on opensuse does not seem working upstream ;)
> Bug 180437 is a good example, works very well on mandriva cooker, do not
>  seem to be fixed upstream :)
> 
I do hope that things will change with the 4.4 release because this bug is as 
old as KDE 4.0. It's full time for it to work on all Distros. I don't know if 
it's the KDE devs fault at this point or the Distros fault because like I 
said, I have no problem with the stable version on openSuse. If I click on  
Login Manager or Yast module in the KDE System Settings then i get a little 
window prompting me to enter my root password. There is no button available. 
It doesn't work in 4.4 though. Don't know why.

#135: It is the fault of both KDE and distros. openSUSE did a temporary patch (probably not applied to development releases); KDE should have incorporated such a temporary workaround and as KDE didn't, other distros should have done so.

Clock KCM = Date & Time.

openSUSE & Kubuntu ( and probably Mandriva ) patch System Settings to launch certain modules with kdesu, this is noticable when they are seperate windows and not integrated into System Settings itself. Their 4.4 packages probably don't contain this patching.

Just to make it clear: Administrator Mode in KDE 4 will never have a seperate button simply because it is not needed. 

Modules inform System Settings if they need authentication and it will take care of launching their helper as root via PolicyKit and D-Bus to perform the action safely and securely when you click Apply.

If the modules don't allow you to change anything then that is a bug with them, please file one.

You can use kcmshell4 --list to get a list of modules, just look for the one you need and take the appropriate name.

Am Freitag 05 Februar 2010 22:16:05 schrieb Ben Cooksley:
> odules inform System Settings if they need authentication and it will take
> care of launching their helper as root via PolicyKit and D-Bus to perform
>  the action safely and securely when you click Apply.
> 
Why should these distros patch something that is working? Without this patch 
there is no way to that one can make certain changes without the console.

Distributions need to do absolutely no patching for modules which already use KAuth, as they work internally in the manner I described.

For as yet unported modules, Distributions should alter the *.desktop files to use System Settings External Application Launching infrastructure, so no patching of System Settings itself should be needed in 4.4.

NOTE: The KAuth infrastructure I describe was only added in KDE SC 4.4!

(In reply to comment #139)
> For as yet unported modules, Distributions should alter the *.desktop files to
> use System Settings External Application Launching infrastructure, so no
> patching of System Settings itself should be needed in 4.4.
> 

Could you please give a (link to) example of such .desktop file, with brief comment of which entries should be added?

Please see http://websvn.kde.org/trunk/KDE/kdebase/workspace/systemsettings/examples/external-application.txt?revision=1020026&view=markup

Essentially just make sure the following line is present:

X-KDE-ServiceTypes=SystemSettingsExternalApp

and make sure X-KDE-ServiceTypes isn't set elsewhere in the file.
To make a module launch as root, change the Exec= line as needed.

(In reply to comment #141)
> Essentially just make sure the following line is present:
> 
> X-KDE-ServiceTypes=SystemSettingsExternalApp

May be I misunderstood you. When I do it, I simply get external window (instead of embedded in system settings) with all the same issues - cannot change anything.

Or do you mean that I need to do this *and* use kdesu at the same time?

But then how can I make resulting window embedded in System Settings?

It is not possible to embed the resulting window as it is an entirely seperate application.

To run it as root, you will need to add kdesu to the front of the executed command.

SVN commit 1130018 by ossi:

make kcm_kdm use kauth

this finally restores the ability to change kdm settings in a
straight-forward way.

BUG: 236415
CCBUG: 151669

patch mostly by
CCMAIL: Igor Krivenko <igor@shg.ru>
Review-URL: http://reviewboard.kde.org/r/3631/

 M  +8 -0      CMakeLists.txt  
 M  +2 -11     background.cpp  
 M  +1 -2      background.h  
 AM            helper.cpp   [License: GPL (v2+)]
 AM            helper.h   [License: GPL (v2+)]
 A             kcmkdm_actions.actions  
 M  +0 -17     kdm-conv.cpp  
 M  +0 -1      kdm-conv.h  
 M  +9 -33     kdm-dlg.cpp  
 M  +0 -1      kdm-dlg.h  
 M  +0 -12     kdm-gen.cpp  
 M  +0 -1      kdm-gen.h  
 M  +0 -13     kdm-shut.cpp  
 M  +0 -1      kdm-shut.h  
 M  +85 -20    kdm-theme.cpp  
 M  +1 -1      kdm-theme.h  
 M  +72 -36    kdm-users.cpp  
 M  +1 -2      kdm-users.h  
 M  +93 -14    main.cpp  
 M  +8 -0      main.h  
 M  +1 -2      positioner.cpp  
 M  +0 -2      positioner.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1130018

The problem IS NOT FIXED AT ALL and is still here in 4.5.1.
For example, you cannot set any system network connection!
Sounds a little bit ridiculous.
Any chance to see this fixed in less than 3 years?

This is fixed, as previously noted. It is up to individual modules to add KAuth support for any privileged operations.

(In reply to comment #146)
> This is fixed, as previously noted. It is up to individual modules to add KAuth
> support for any privileged operations.

As long as those individual modules are part of KDE it is still a KDE problem that is NOT FIXED. So I suggest the KDE team to actually do something to fix this or face the discontent and loss of users due to the poor quality of the piece of software they provide.

Modules with issues need seperate bug reports filed against them.

(In reply to comment #148)
> Modules with issues need seperate bug reports filed against them.

Yes. Is the KDE team going to wait until users report all such modules or are they able to do their QA internally?

Please also post the list of separate bug reports here.

So, re-submit your complaint, but make it clear that the issue is not with
system settings itself, but with the module that has not added KAuth support.
Unless your report is directed to the maintainer of the module causing your
issue, it is unlikely that it will ever get fixed. When the triage team looks
at bug reports, they direct the report to the maintainer of the project named
in the report. If the report names the wrong project, it gets directed to the
wrong maintainer.

If the maintainer of the problem project does not know about an issue, (s)he
will not know to fix it. KDE is a very large organization. Most of the people
who maintain the software are volunteers. They work a full time job to support
themselves, then when they are not working that full time job, they work on the
project for which they have volunteered. They do not have the time it would
require to go looking for bugs they have not been informed about (and why would
they?). I for one am most grateful that they put in the amount of time they do.
Since we (the KDE user community) benefit from their efforts at no cost to us,
I think that the least we can do is to put in the effort to help them (the KDE
development community) by re-submitting bug reports with better information
when we learn that our report has not been directed to the maintainer who can
fix the problem.

I hope I have not offended anyone with this post. I only want to help those new
to Open Source Software better understand how it works. If I have offended
anyone, please accept my apologies.

Am Freitag 15 Oktober 2010, 08:31:01 schrieb Jaak Ristioja:
> https://bugs.kde.org/show_bug.cgi?id=151669
> 
> 
> 
> 
> 
> --- Comment #149 from Jaak Ristioja <Ristioja gmail com>  2010-10-15
> 08:31:00 --- (In reply to comment #148)
> 
> > Modules with issues need seperate bug reports filed against them.
> 
> Yes. Is the KDE team going to wait until users report all such modules or
> are they able to do their QA internally?
> 
> Please also post the list of separate bug reports here.

This Administrator mode bug is around since KDE 4.0. Sometimes I get the 
impression that features are more important than ironing out the glitches. 
There are a few other little things that are around for years now and nerve 
but nobody seems to care about fixing them.
KDE 4 has more than enough killer features. What users really need is speed, a 
reliable and very responsive desktop.  Get these things in KDE 4 right and it 
will be the clear winner.

As far as I am aware, no module currently shipped is broken due to the loss of Administrator mode. KDM and Clocks, the only two modules which used it, have since been fixed. 

Network Management is a seperate issue as System Connections have to be created in a different manner to User Connections.

Please report those modules which still have issues as seperate bugs.

i can't change photo of my account with systemsettings, also if i open with sudo, sudo -s.

it says to me that the admin does't want that i change the photo... but i'm the administator!!!

(In reply to comment #153)
> i can't change photo of my account with systemsettings, also if i open with
> sudo, sudo -s.
> 
> it says to me that the admin does't want that i change the photo... but i'm the
> administator!!!

Hello,
that sounds like a different problem.  Please open a new bug against this issue.