cups-pk-helper/PolicyKit does not provide the desired authentication modes for system-config-printer

[Till Kamppeter]

The problem is that when cups-pk-helper is installed system-config-printer switches its authentication method for administrative tasks from CUPS' built-in IPP authentication to Policy-Kit-based authentication. This means that the access control via the "lpadmin" group gets dropped. So an adminstrator user like the first user installed in Ubuntu (is in the "lpadmin"group) cannot do printer administration without entering a password any more. For all administrative tasks a password dialog from PolicyKit pops up, independent whether the calling user (the user currently logged in on the desktop) is administrator and/or in the lpadmin group.

It would be great if cups-pk-helper would give the possibility to allow access for users in the admin group (in the lpadmin group) without asking for their password if they are logged in on the desktop already.

See also the IRC discussion between me (tkamppeter) and Martin Pitt (pitti) on #ubuntu-devel on FreeNode today below.

In Oneiric we have applied a workaround, simply disabling PolicyKit support in system-config-printer (see bug 807261).

----------
<tkamppeter> pitti, it is about bug 807261, the problem of cups-pk-helper breaking s-c-p.
<ubottu> Launchpad bug 807261 in cups-pk-helper (Ubuntu Oneiric) "cups-pk-helper makes system-config-printer asking for a password when adding a new printer" [High,New] https://launchpad.net/bugs/807261
<tkamppeter> pitti, I have added a longer comment to it.
<tkamppeter> pitti, have you seen my message above?
<pitti> tkamppeter: yes; do you need me to do anythign with this bug?
<tkamppeter> pitti, I want to know what you think is the best solution without loosing any functionality.
<tkamppeter> pitti, There are the following possibilities:
<pitti> why do we need cups-pk-helper?
<pitti> for s-c-p?
<pitti> we haven't before
<pitti> I thought it's only needed for the upstream control-center printer capplet
<pitti> (which we don't use in ubuntu/unity, just with gnome shell
<tkamppeter> pitti, s-c-p does not need cups-pk-helper, so if there is nothing else needing it, one could simply make sure that it does not get pulled into the default installation.
<pitti> tkamppeter: it doesn't
<pitti> tkamppeter: if you install gnome-shell, it will be pulled in
<tkamppeter> pitti, what pulls it in currently is gnome-shell and gnome-shell I have installed, probably because my Oneiric is grown out of daily updates from Natty.
<pitti> does it hurt to have it installed?
<tkamppeter> pitti, we must assure that updaters from Natty and older will not get cups-pk-helper pulled in.
<pitti> the upstream capplet is hidden in the control center under UNity
<pitti> so nothing ought to invoke it?
<pitti> tkamppeter: why?
<pitti> tkamppeter: I thought s-c-p wouldn't use cups-pk-helper; you mean it does?
<tkamppeter> pitti, yes, if cups-pk-helper is installed, s-c-p asks for an admin password, even if the user is in the lpadmin group.
<pitti> bah
<pitti> it oughtn't
<pitti> tkamppeter: can we disable cups-pk-helper support in s-c-p easily? does it have a configure option?
<tkamppeter> pitti, I can also patch away the cups-pk-helper support in s-c-p by adding only two lines.
<tkamppeter> pitti, it is not a configure option, it is setting a variable to False at two points.
<pitti> tkamppeter: do you think that would be okay? it seems like the best solution to me
<tkamppeter> pitti, best solution would be to fix cups-pk-helper to support the user-in-lpadmin-group case, but probably this is more work, and not easy to project into the architecture of PolicyKit.
<pitti> tkamppeter: right
<pitti> tkamppeter: I think if/when we switch to cups-pk-helper and the upstream applet, we'll deprecate lpadmin in the desktop
<pitti> it's one of the few "hardware access" groups that we still have, and it's a thorn in the eye
<pitti> tkamppeter: we can then even configure polkit to allow access to local printers from a local desktop session (as these users have physical access anyway)
<tkamppeter> pitti, another solution would s-c-p trying cups authentication not allowing a password prompt and only if the authentication fails try cups-pk-helper and as last mean try cups authentication with password. But this would be a bigger change, perhaps not doable for Oneiric.
<pitti> tkamppeter: yeah, that even sounds upstreamable then
<tkamppeter> pitti, this would be a good idea, switch to PolicyKit instead of lpadmin-group-based access in s-c-p (keep lpadmin group only for the command line utils of CUPS) and allowing general access to locally defined print queues for local desktop users.
<tkamppeter> s/general access/general passwordless access/
<tkamppeter> pitti, for me it looks like that the quickest solution to solve the s-c-p/cups-pk-helper incompatibility problem in Oneiric is to apply the 2-line patch to make s-c-p not using cups-pk-helper.
<tkamppeter> pitti, letting s-c-p try password-less CUPS auth before PK auth and then passworded CUPS auth is a good idea to suggest upstream, too complicated to rush into Oneiric.
<tkamppeter> pitti, I am trying now another possible solution: Using, as you suggested, cups-pk-helper but opening up the right to manipulate local queues for all local desktop users without password. password is only needed for server settings and manipulating remote printers.
<tkamppeter> pitti, this I am doing by replacing most "auth_admin_keep" by "yes" in /usr/share/polkit-1/actions/org.opensuse.cupspkhelper.mechanism.policy.
<tkamppeter> pitti, WDYT? Which method should we use in Oneiric?
<tkamppeter> pitti, if we opt for using the cups-pk-helper-based solution, I can patch s-c-p to check for the SSH_CLIENT env variable to not use PK is s-c-p is run through SSH, a ~6 lines patch.
<pitti> tkamppeter: no, please don't replace with "yes", we should only do that for users who are in the "admin" group already
<pitti> tkamppeter: I think for oneiric we should just do the 2-line patch you suggested
<tkamppeter> pitti, OK, will do so.
<pitti> tkamppeter: thanks
<tkamppeter> pitti, admin-group-only authentication (but asking for password) is the standard scenarion if one does not change the cups-pk-helper configuration. Would be great if cups-pk-helper would give the possibility to allow access for users in the admin group (in the lpadmin group) without asking for their password if they are logged in on the desktop already.
<pitti> tkamppeter: yes, that's possible, just not in the .policy file
<pitti> tkamppeter: but as we don't use cups-pk-helper, I wouldn't change it in oneiric now
<tkamppeter> pitti, so this would be a feature request for cups-pk-helper in Powerful Pitti, our next LTS.
<pitti> tkamppeter: heh
<pitti> tkamppeter: actually it would go into policykit-desktop-privileges, but either way, it's a simple change; I can do it easily
<tkamppeter> pitti, great. Will you add this to your TODO list or should I report a bug?
<pitti> tkamppeter: bug report will do fine
<pitti> we can target it to P

[Launchpad Janitor (janitor)]

This bug was fixed in the package policykit-desktop-privileges - 0.9

---------------
policykit-desktop-privileges (0.9) precise; urgency=low

  * Allow members of "lpadmin" or "admin" to call the cups-pk-helper methods
    without a password. cups itself only checks for lpadmin membership, so
    this provides an equivalency. (LP: #847896)
 -- Martin Pitt <email address hidden> Wed, 09 Nov 2011 12:55:57 +0100