Description of problem: When starting system-config-printer from the gnome menu, changes are not allowed because user privileges are not escalated. Version-Release number of selected component (if applicable): system-config-printer 1.1.13-10.fc12.x86_64 probably more related to gnome subsystem. How reproducible: Click System->Administration->Printing Printer Configuration is launched, but no changes are allowed. Steps to Reproduce: 1. Click System->Administration->Printing 2.Printer Configuration is launched, but no changes are allowed. 3. Actual results: Not allowed to add/edit/change Expected results: Allow add/edit/change Additional info: Updated Fedora 12. Running LTSP. Results from thinclient desktop. Have not tried from the actual server.
Thinclient desktop -- is that VNC? If so, you need to configure PolicyKit to allow appropriate access to printing configuration changes, something like this: # cat <<EOF >/var/lib/polkit-1/localauthority/50-local.d/10-printing-policy.pkla [Desktop Administrator Permissions] Identity=unix-group:desktop_admin_r Action=org.fedoraproject.config.*;org.opensuse.cupspkhelper.mechanism.* ResultAny=auth_self ResultInactive=auth_self ResultActive=yes EOF This will allow users in the desktop_admin_r group to perform such changes when they authenticate themselves (by providing their login password). Tune as needed. See 'man pklocalauthority' for the syntax of that file. Does that answer your query?
Sorry, that should read: # cat <<EOF >/var/lib/polkit-1/localauthority/50-local.d/10-printing-policy.pkla [Desktop Administrator Permissions] Identity=unix-group:desktop_admin_r Action=org.opensuse.cupspkhelper.mechanism.* ResultAny=auth_self ResultInactive=auth_self ResultActive=yes EOF
>Thinclient desktop -- is that VNC? No...I am using LTSP and pxe booting my clients. I tried applying your suggested fix anyway and it still doesn't work. Thank you!
(In reply to comment #3) > No...I am using LTSP and pxe booting my clients. But you are running system-config-printer on the server and having it display on the clients? Rather than running system-config-printer directly on the clients? > I tried applying your suggested fix anyway and it still doesn't work. It's not a fix -- as far as I have been able to tell so far there's no bug. It's a configuration issue for your particular case. The default policy for cups-pk-helper is that active console users must provide administrative authentication, and no-one else (e.g. remote users) gets to even try that. Did you add your user to the desktop_admin_r group?
Thank you for your help on this issue. Your suggestion did end up working after rebooting the server. I'm not really sure how I would have found an answer without your help. I learned something new. I'm sure there is a good reason why by default it doesn't attempt privilege escalation for anyone starting that applet regardless of how they are connected to the desktop. Couldn't that be made to be the default? Would that be considered a feature request instead of a bug report? Anyway. Thank you again. I really appreciate your time and support. (In reply to comment #4) > (In reply to comment #3) > > No...I am using LTSP and pxe booting my clients. > > But you are running system-config-printer on the server and having it display > on the clients? Rather than running system-config-printer directly on the > clients? > > > I tried applying your suggested fix anyway and it still doesn't work. > > It's not a fix -- as far as I have been able to tell so far there's no bug. > It's a configuration issue for your particular case. > > The default policy for cups-pk-helper is that active console users must provide > administrative authentication, and no-one else (e.g. remote users) gets to even > try that. > > Did you add your user to the desktop_admin_r group?
Is there anyway to grant the application escalated privileges upon launching instead of prompting for a password for each action? (The way it works when on a local desktop?) Although this does provide a work-around, it is rather annoying to keep having to enter the password for each action. I had the same issue with the add/remove programs app and when I applied this solution, it prompts me for each package to be installed/removed. Would the answer be to change the launch shortcuts to invoke beesu first? (I can't find gksu)
(In reply to comment #6) > Is there anyway to grant the application escalated privileges upon launching > instead of prompting for a password for each action? (The way it works when on > a local desktop?) It doesn't work that way on a local desktop, and the application is not granted any more privileges than it originally had. The privileged operations are performed by a helper mechanism guarded by PolicyKit. The policy is defined on a per-operation level so authentication can only be requested when a privileged operation is carried out, not just "generally" at application start-up. > Although this does provide a work-around, it is rather > annoying to keep having to enter the password for each action. Perhaps set your local policy to "auth_self_keep" or some such. (See "man polkit".) (In reply to comment #5) > Thank you for your help on this issue. Your suggestion did end up working after > rebooting the server. I'm not really sure how I would have found an answer > without your help. The policykit 1.0 documentation is quite new, and there is not much in the way of configuration tools for it -- specifically there is not yet a graphical user interface, or a selection of example policies. :-( > I learned something new. I'm sure there is a good reason why > by default it doesn't attempt privilege escalation for anyone starting that > applet regardless of how they are connected to the desktop. Couldn't that be > made to be the default? Would that be considered a feature request instead of a > bug report? A feature request for cups-pk-helper -- I've changed this bug report into that. To restate: ==> The default cups-pk-helper PolicyKit policy is "no" for inactive/any users but this doesn't make very much sense. The underlying CUPS policy is to request admin authentication and users can take advantage of that anyway using other tools. A better default PolicyKit policy for inactive/any users is "auth_admin". <== Reassigning.
Hi, I changed inactive sessions policy and any users policy to "auth_admin". The build is cups-pk-helper-0.0.4-9.fc12. Regards Marek
cups-pk-helper-0.0.4-9.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/cups-pk-helper-0.0.4-9.fc12
cups-pk-helper-0.0.4-9.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
I just logged in to say "thank you". This post from almost 5 years ago helped me sort out an issue - or at least got me on the right track. # cat <<EOF >/var/lib/polkit-1/localauthority/50-local.d/10-printing-policy.pkla [Desktop Administrator Permissions] Identity=unix-group:desktop_admin_r Action=org.opensuse.cupspkhelper.mechanism.* ResultAny=auth_self ResultInactive=auth_self ResultActive=yes EOF