Red Hat Bugzilla – Bug 652272
No automagic escalation of privileges to add a printer
Last modified: 2011-05-24 10:07:57 EDT
Description of problem:
Trying to add a new printer leads to an error stating, "Not Authorized" "The password maybe incorrect"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. KDE Button -> System Settings -> Printer Settings -> New Network Printer
Fails as mentioned in the description
Query for the password or some other means of escalating the privilege of the application.
Works for me with system-config-printer using GNOME.
system-config-printer-kde is part of the kdeadmin package. Reassigning.
Confirming with system-config-printer-kde-4.5.3-1.fc14.x86_64
I'm new to KDE.
Had been using GNOME up to last week when I installed F14 with KDE.
Just now I have realized that there's some s-c-p-kde package in KDE.
Wonder what is it good for.
What it does that system-config-printer doesn't ?
I don't see anything special except that
- I can't add new printer (this bug)
- all options in Server Setting are greyed so I can't change anything there (another bug)
- there are no Advanced Server Settings so I can't add 'Browse servers', which is the easiest way how to use printers in our office
Created attachment 468373 [details]
Running via the command line
Created attachment 468374 [details]
Running via the GUI
I can confirm this with the current 4.5.4 KDE SC. Running "kdesu kcmshell4 system-config-printer-kde" from the command line starts the printer configuration with the right privileges, but directly using the GUI fails. See the 2 attached screenshots for the working and not working examples!
*** Bug 668665 has been marked as a duplicate of this bug. ***
Still a problem in F15.
Created attachment 500053 [details]
dialog asking me for root's password
Seems to be fixed with
To be clear,
* Fri Apr 08 2011 Rex Dieter <email@example.com> 7:4.6.2-2
- No automagic escalation of privileges to add a printer (#652272)
the only thing fixed is systemsettings->printers , not right-click printer-applet... yada yada or any other method of launching this (I suppose we could add more kdesu usage everywhere, but that's a rabbit-hole I'm not sure I'm willing to go down).
Doing any better will require upstream to port this to use KAuth properly
Using kdesu is the wrong fix.
system-config-printer does not need any root privilege in order to do its job. It does, however, need to authenticate with cupsd, and cups-pk-helper allows this to happen via D-Bus and polkit.
This is all working fine in GNOME; if it isn't working in the KDE "version", that's a bug in that version.
emphatically agreed, that's the origin of my "upstream needs to port this to use KAuth properly" comment.
(we downstream are not in a position to implement that ourselves anytime in the foreseeable future.
As a matter of fact, I'd personally just rather use system-config-printer that "just works", than continue the facade of a kinda-sorta-but-not-really-workable system-config-printer-kde, but that's another battle.
There won't be any KAuth support in system-config-printer. What's wrong with using D-Bus and polkit? Surely KDE has an authentication agent for it...?
I think we agree, though may be talking past each other. let me clarify, that when I mean upstream in the past couple of comments, I mean system-config-printer-kde, and that adding KAuth support essentially means using dbus/polkit properly for privledges.
The question is: What code is responsible for the privilege escalation authentication? Is it the shared code in system-config-printer-libs or the UI code in system-config-printer(-kde)?
If it's the shared code, why does this not just work? We need to debug this.
If it's the UI code, then system-config-printer-kde needs some code using PolicyKit and D-Bus (or a wrapper around them, e.g. KAuth or python-slip) which it currently doesn't have.
I really wonder what system-config-printer (the GTK+ UI) does differently from system-config-printer-kde there.
There is no privilege escalation; only delegation.
The cups-pk-helper package is responsible for providing a system D-Bus interface for performing administrative operations on the local CUPS server. This D-Bus interface is polkit-enabled, and KDE is responsible for providing an authentication agent.
`--> cups-pk-helper -> polkit -> authentication agent
The particular parts of system-config-printer that talk to cups-pk-helper:
The authentication agent is there (polkit-kde), it looks like what's missing in system-config-printer-kde is the "system-config-printer --> cups-pk-helper" part of the diagram.