Bug 749451

This is defined in /etc/polkit-default-privs.standard:

#
# system-config-printer
#
org.opensuse.cupspkhelper.mechanism.printer-set-default         auth_admin_keep
org.opensuse.cupspkhelper.mechanism.printer-enable              auth_admin_keep
org.opensuse.cupspkhelper.mechanism.printer-local-edit          auth_admin_keep
org.opensuse.cupspkhelper.mechanism.printer-remote-edit         auth_admin_keep
org.opensuse.cupspkhelper.mechanism.class-edit                  auth_admin_keep
org.opensuse.cupspkhelper.mechanism.server-settings             auth_admin_keep
org.opensuse.cupspkhelper.mechanism.printeraddremove            auth_admin_keep
org.opensuse.cupspkhelper.mechanism.job-edit                    auth_admin_keep
org.opensuse.cupspkhelper.mechanism.job-not-owned-edit          auth_admin_keep
org.opensuse.cupspkhelper.mechanism.devices-get                 auth_admin_keep
org.opensuse.cupspkhelper.mechanism.all-edit                    auth_admin_keep

This has nothing to do with Gnome od KDE or whatever
desktop environment or whatever application program.

Since ever one needs admin privileges to set up a print queue.
Since ever the default is that only root has admin privileges.

The issue is never ever a "major" bug.
It is even not a bug at all.
It is just as it is since ever.

If you like to change the default which users should
have admin privileges, file a FATE request because this
causes major security issues which must be discussed in detail.

Regarding admin privileges to set up a print queue:
If root likes, he can change the so called "CUPS Operation Policy"
so that any user can do any kind of printer admin task, see
http://en.opensuse.org/SDB:CUPS_in_a_Nutshell

Hint:
Regarding CUPS policies, have a look at the YaST printer module.

Johannes: your comment completely ignores the fact that system-config-printer users cups-pk-helper. So this is not about the cups security settings, but about the cups-pk-helper ones.

Oops!
I forgot that the desktop environment does all on its own.

I just tested this with a local USB printer attached to my 12.1 system and can confirm the problem on the GNOME desktop.

Ludwig, Marcus, it seems to me that the default security settings (see comment#1) are not correct. Could you look at this, please?

on Ludwigs machine we attached a HP Deskjet 990, it got automatically detected
and set up.

Please bring hardware.

I tested now all my printers ;)

My deskjet 950C got added automatically as well.

My LaserJet CP1525n had no PPD file found and I selected the 1520n PPD file - and then a password was needed.

Details:
First "Missing printer driver - no printer driver for HP LaserJet CP1525N"
Pressing "Search" a popup opens and I press "Select printer from database" where I choose the Laserjet CP1520 and then press "Apply" in the "Describe printer" dialog - and get a dialog that says "Privileges are required to add/edit/remove a local printer" and asks for root password.

Sorry, the printer is too heavy to carry around but should be able to reproduce with removing the PPD file for your printer.

Is the handling of the LaserJet really correct?

Btw. reread the description from Gerald - if you do it as he says, you need directly a root password.

Vincent Untz,
I have a question regarding your comment #3
which is a bit off-topic but I think it is related to the issue:

Because you wrote "this is not about the cups security
settings, but about the cups-pk-helper ones" I wonder
to what extent cups-pk-helper works in compliance
with the CUPS security settings - i.e. the so called CUPS
Operation Policies (who is allowed to do what in CUPS), see
http://www.cups.org/documentation.php/doc-1.5/policies.html

I mean: If the CUPS Operation Policies allows something
(e.g. that any user can do printer admin stuff), does then
also cups-pk-helper allow the same and vice versa if the
CUPS Operation Policies forbid or require something
(e.g. all users must in any case authenticate)
does then also cups-pk-helper forbid or require the same?

Does cups-pk-helper work in compliance with CUPS Operation Policies?

No, it doesn't; it's a different set of policies, which are defined the policykit way. We've done it this way to offer a consistent way to define policies on the machine (in the very same way we define a policy for reboot/shutdown, for instance)..

Then let's hope admins who use CUPS Operation Policies
to specify who is allowed to do what in CUPS know that
they also have to check what cups-pk-helper
(i.e. PolicyKit) might allow or forbid.

FYI:
Regarding the CUPS Operation Policies setup
(allow printer admin tasks for a normal user)
there is now
https://features.opensuse.org/313287

Vincent Untz,
do you think it is somehow possible to get the
CUPS Operation Policies settings and the PolicyKit settings
for cups-pk-helper automatically aligned?
I mean that when the admin cahnges one of them,
an automatism adapts the other one.

(In reply to comment #11)
> do you think it is somehow possible to get the
> CUPS Operation Policies settings and the PolicyKit settings
> for cups-pk-helper automatically aligned?
> I mean that when the admin cahnges one of them,
> an automatism adapts the other one.

Our PolicyKit settings are controlled by polkit-default-privs (and set_polkit_default_privs, that applies the defined policies).

I guess something could try to synchronize the settings between the cups config and /etc/polkit-default-privs.local, though.

FYI:
Regarding the issue starting at comment#8 there is now bnc#827331
"Gnome printing policies are not in compliance with CUPS policies".

I get the feeling this is currently working fine (at least here I could not reproduce it).
Gerald could you please move it to current release if it is still present?