"Add Printer" dialog requests root password if user is not in Configure Printers group

Status changed to 'Confirmed' because the bug affects multiple users.

As a workaround for the time being, please add all user accounts from where you want to do printer administration to the "lpadmin" group.

Do not forget to remove them again when we suggest a fix for testing.

What one is supposed to do is to enter user name and password of a user who is in the lpadmin group. I have tried that running system-config-printer on the desktop of a test user (not in lpadmin) and entering the credentials of the first user installed (is in lpadmin).

Unfortunately, and this is a real bug, either in system-config-printer or in some authentication infrastructure in Ubuntu, the credentials do not get accepted and s-c-p falls into an unbreakable infinite loop of the credentials dialog and the dialog telling that the credentials are not correct.

Tim, can you look into that?

You could also run gksudo. No need to play with the user privs then.

> s-c-p falls into an unbreakable infinite loop of the credentials dialog and the dialog telling that the credentials are not correct.

This seems to be a change in behaviour for CUPS. It used to be that providing an empty string for the password from the auth callback would cancel the operation, but this no longer seems to be the case.

(e.g. try some lpadmin command... just pressing enter at the password prompt used to quit)

Tim, I tried the following:

----------
till@till:~$ sudo su - test
[sudo] password for till:
test@till:~$ /usr/sbin/lpadmin -p testqueue -E -v /dev/null
lpadmin: Forbidden
test@till:~$ /usr/sbin/lpadmin -U till -p testqueue -E -v /dev/null
Password for till on localhost?
lpadmin: Unauthorized
test@till:~$ /usr/sbin/lpadmin -U till -p testqueue -E -v /dev/null
Password for till on localhost?
test@till:~$ lpstat -v testqueue
device for testqueue: /dev/null
test@till:~$ exit
logout
till@till:~$ lpadmin -x testqueue
till@till:~$
----------

"till" is in the "lpadmin"group, "test" not. On the first "/usr/sbin/lpadmin -U till ..." command I simply pressed Enter on the password prompt and the command exited immidiately, on the second command I entered the correct password and the queue got created. Entering a wrong, non-empty password leads to a new password prompt, also entering nothing on the new prompt closes lpadmin.

So CUPS seems to behave correctly.

Is this with CUPS 1.5, or an older version?

Yes, CUPS 1.5. And the command line tests above, too. All on the same machine.

Tim, I have tried pycups 1.9.59 now. It brings me significantly further but still does not completely fix this issue.

The infinite loop when entering no password or clicking "Cancel" is gone. So one can at least get out of s-c-p again if one has no valid credentials to manipulate print queues.

I have also tried, being on the desktop of the user "test" (see comment #6) running system-config-printer, clicking "Add" and then enter the user name "till" and the appropriate password. In this case the device list gets loaded (printer auto-detection, this did not work before) and I can continue setting up the print queue, but now the problem is at the end of the wizard. When I click on "Apply" I get an error message: "CUPS server error: There was an error during the CUPS operation: 'cups-authorization-canceled'". I can close the wizard only by clicking "Cancel" and the queue does not get created. What I expect is that the authentication in the beginning gets used for the rest of this system-config-printer session.

This behaves the same independent whether cups-pk-helper is installed or not.

I tried also another operation: Still on "test"s desktop I closed system-config-printer and started it again. This time I tried to remove a queue by right-clicking its icon and choosing "Delete" in the menu. After confirming I did not get any login/password dialog but directly the message "CUPS server error: There was an error during the CUPS operation: 'cups-authorization-canceled'".

See if ef59305 fixes it.

Tim, thank you very much.

It is an important step forward as now one can at least create the queue.

Problem is that there are two login/password prompts now, one to authorize for polling the list of available printers and a second to authorize the creation of the queue. Could you make it keeping the credentials for the whole system-config-printer session? Or at least for the live of the add-printer wizard? Could you also remove the pre-filled "root" user name? Thanks.

Tim, one additional remark to above-mentioned problem:

There seems to be a CUPS connection with credentials for the main process of the s-c-p session and separate CUPS connections with their own credentials for asynchronous background processes like polling the list of detected printers.

If one logs in on the main CUPS connection first, for example by the first action being option default settings of an existing print queue, one can afterwards create a queue without getting asked for login/password again, but if the first action in the session is creating a queue, one gets asked at first before the list of detected devices gets shown and a second time at the end of the add-printer wizard when the queue gets created. But after that one can set option defaults of all existing printers without getting asked again.

In addition, when I have already created a printer or changed option settings of an existing printer and after that I try to remove a printer I get asked again, but starting the session with removing a printer allows changing option settings of another still existing printer without entering the credentials again. The login for deleting a printer also stays valid for the whole process of creating a new queue afterwards.

So prinmter deletion seems to have the most powerful authentication which stays valid for all the other actions, after that comes changing printer option settings which at least allows creating queues afterwards. The weakest seems to be listing detected printers as a new authentication for creating a queue is required.

Can you make this consistent, so that when the user logs in once so that he can do everything during the rest of the s-c-p session, independent of which he did first? Thanks.

The pre-filled "root" username only appears when the user's own username was tried and got forbidden (i.e. they authenticated but were not authorized).

I'm not particularly interested in tinkering with the credentials cache very much, but if you want to play with it feel free to send patches.

Tim, IO have found bugs in the password caching and found a fix for them in a relatively small patch. Currently I am testing this.

I have packaged the fixes now and uploaded new python-cups and system-config-printer packages for a 0-day SRU. They are waiting for approval in the oneiric-proposed package repository now.

debdiff for python-cups

debdiff for system-config-printer

Note: The system-config-printer update depends on the python-cups update.

Hello Matt, or anyone else affected,

Accepted python-cups into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

The fix in python-cups only prevents an infinite loop of the login/password pop-up, so that it does not appear again when clicking "Cancel". So you are at least able to close the add-printer wizard. But note that you are still not able to actually log in using user name and password of an authorized user (user in "lpadmin" group, first user set up). This requires also the update of system-config-printer.

With both updates all works correctly:

- No prompt 'Password for "root" at localhost', No pre-filled "root" in user name field
- Canceling the login/password dialog closes it without it popping up again.
- Entering nothing, invalid credentials, wrong password, or unauthorized user and then clicking OK, gives "Not authorized" error pop-up and afterwards the login/password dialog appears again.
- Entering correct credentials allows the current administrative operation and all further administrative operations until closing system-config-printer, without any further login/password dialog.

Please test also this as soon as the update for system-config-printer gets approved.

Hello Matt, or anyone else affected,

Accepted system-config-printer into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Fix verified by Lars Uebernickel (larsu) during phone meeting with me. Bug fix verified.

This bug was fixed in the package python-cups - 1.9.59-0ubuntu0.1

---------------
python-cups (1.9.59-0ubuntu0.1) oneiric-proposed; urgency=low

  * New upstream bug fix release
     o CUPS password callback: Return NULL instead of the empty string when
       handling an exception or when the callback returned an empty string,
       and handle the callback returning None. This avoids infinite password
       dialog loops (LP: #653132).
 -- Till Kamppeter <email address hidden> Tue, 04 Oct 2011 15:58:18 +0200

This bug was fixed in the package system-config-printer - 1.3.6+20110831-0ubuntu9.1

---------------
system-config-printer (1.3.6+20110831-0ubuntu9.1) oneiric-proposed; urgency=low

  * debian/control: Depend on python-cups 1.5.59 (LP: #653132).
  * debian/patches/67_no-misleading-prompt-and-root-default-in-auth-dialogs.patch:
    Do not show the misleading prompt 'Password for "root" on localhost', as
    under Ubuntu you do not log in as root. Also do not pre-fill "root" as
    default user name (LP: #653132).
  * debian/patches/65_do-not-connect-to-cups-with-empty-username.patch: Do not
    connect to CUPS with an empty user name (LP: #653132).
  * debian/patches/63_repeat-authorization-when-try-as-root-fails-asyncipp.patch:
    On asynchronous IPP connections make sure that the password dialog is
    repeated if a wrong password is entered (LP: #653132).
  * debian/patches/60_fix-password-cache.patch: Fixes in caching the entered
    password, to assure that only one password prompt happens during the whole
    system-config-printer session (LP: #653132).
  * debian/patches/57_fix-broken-setting-of-ipp-auth-canceled-constant.patch:
    Upstream uses a constant of python-cups 1.5.60 and has a fallback to an
    explicit definition when an older python-cups is used. This fallback
    mechanism is broken and this patch works around it.
  * debian/patches/55_handle-new-cups-1.5-ipp-error-response-ipp-authentication-canceled-asyncipp.patch:
    Fix to distinguish canceling of authentication from entering an empty
    password (asynchronous IPP connections, #653132).
  * debian/patches/53_handle-new-cups-1.5-ipp-error-response-ipp-authentication-canceled-authconn.patch:
    Fix from upstream to distinguish canceling of authentication from entering
    an empty password (synchronous IPP connections, #653132).
 -- Till Kamppeter <email address hidden> Sun, 9 Oct 2011 01:32:24 +0200

Raring: Issue regressing in raring (latest updates as of 08-Mar-2013)

I believe I have encountered this issue in a fresh install of Trusty. I was able to add a network printer only with "gksudo system-config-printer". Otherwise, my credentials were refused and I could get part way through printer installation, but could never complete it. I could cancel so the credentials dialog went away, but it came up again when I clicked on "apply" at the end of the install.

I'm seeing a very similar problem. I ran into this both upgrading from 13.04 to 13.10 and then from 13.10 to trusty. Specifically, I see the following:

Setting up cups (1.7.2-0ubuntu1.1) ...
Updating PPD files for cups ...
Updating PPD files for foomatic-db-compressed-ppds ...
Password for root on localhost?
Password for root on localhost?
Password for root on localhost?
Password for root on localhost?
[Repeated in response to any input I supply, including ^c and ^d. ]

The only "solution" I found was to kill the installation process, manually remove foomatic-db-compressed-ppds, and then attempt to resume the installation with dpkg and apt-get directly.

Ditto for package "gutenprint" although in this case ^c caused the dpkg process to continue smoothly.

Setting up cups (1.7.2-0ubuntu1.1) ...
Updating PPD files for cups ...
Updating PPD files for foomatic-db-engine ...
Updating PPD files for openprinting-ppds ...
Updating PPD files for c2esp ...
Updating PPD files for foo2zjs-common ...
Updating PPD files for gutenprint ...
Password for root on localhost?
Updating PPD files for hpcups ...

(same as bug #387970)
Reproduced the problem in Ubuntu 14.04 with this command in a "root" session:

lpadmin -p "Create_PDF" -v 'cups-pdf:/' -m "$Generic CUPS-PDF Printer" -P "/usr/share/ppd/cups-pdf/CUPS-PDF.ppd" -L "Personal PDF folder" -o 'printer-is-shared=false' -E

Environment: Live session (u14.04) and chroot into the system I need to setup. In chroot environment there isn't normal user session (only root).

To root user uses lpadmin, do I need to add "root" to "lpadmin" group??!

Still reproducable on 15.10 (Kubuntu)

I got affected by this in Ubuntu 20.04. How come? In the status above it says "Fix released". Am I missing something?