Bug 596711 - Local printer policy too strict
Summary: Local printer policy too strict
Alias: None
Product: Fedora
Classification: Fedora
Component: cups-pk-helper
Version: 17
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
: 658555 (view as bug list)
Depends On:
Blocks: 595007
TreeView+ depends on / blocked
Reported: 2010-05-27 11:05 UTC by Tim Waugh
Modified: 2013-04-23 15:03 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-04-23 15:03:04 UTC
Type: ---

Attachments (Terms of Use)
Screenshot from "gnome-control-center printers" asking for password (35.83 KB, image/png)
2012-06-14 09:50 UTC, Valent Turkovic
no flags Details

Description Tim Waugh 2010-05-27 11:05:14 UTC
Description of problem:
The file /var/lib/polkit-1/localauthority/10-vendor.d/10-desktop-policy.pkla lists several action patterns that users in the desktop_admin_r group should be able to perform:


Is it intentional that these are missed out?:


Version-Release number of selected component (if applicable):

Comment 1 Steven Haigh 2010-09-14 05:49:17 UTC
This also seems to be an issue in F14 with:

I am required to enter the root password 3 times to add a printer.

Comment 2 Stephen John Smoogen 2010-10-05 16:09:48 UTC
How does one add themselves as desktop_admin_r group?

Comment 3 Tim Waugh 2010-10-05 16:23:13 UTC
With the Users and Groups tool.  Select user, click Properties, select Group tab, tick desktop_admin_r group, click OK.

Comment 4 Steven Haigh 2010-10-05 16:29:28 UTC
Ah. Nice tip Tim. Should save me quite a few password entries ;)

Comment 5 Steven Haigh 2010-10-05 16:31:31 UTC
Oh, and for what its worth, these are still missing in F14.

Comment 6 Stephen John Smoogen 2010-10-05 16:38:41 UTC
SLAM. That is my hand against my head. I thought these were capability/Selinux items from their name and not /etc/group. 

groupadd -a -G desktop_admin_r <username> works also in that case.

Comment 7 Steven Haigh 2010-10-05 16:40:20 UTC
(In reply to comment #6)
> SLAM. That is my hand against my head. I thought these were capability/Selinux
> items from their name and not /etc/group. 
> groupadd -a -G desktop_admin_r <username> works also in that case.

Yeah - to be honest, I thought they were for selinux stuff too - but didn't quite understand what was going on. Tims comment above turned on the lightbulb for me too :)

Comment 8 Tim Waugh 2010-11-30 18:38:03 UTC
*** Bug 658555 has been marked as a duplicate of this bug. ***

Comment 9 Tim Waugh 2010-12-06 11:39:08 UTC

Would be great to get this fixed.

Comment 10 Bug Zapper 2011-06-02 13:16:13 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 11 Tim Waugh 2011-06-02 13:31:55 UTC
Yes, still applies to Fedora 15.  However there is now this:


which specifies 'wheel' as an administrative group.  Should I also modify our default /etc/cups/cupsd.conf so that it recognises 'wheel' as a system group?

Comment 12 Ben Boeckel 2011-11-09 04:49:43 UTC
It'd be nice for wheel to have authorization for org.freedesktop.UPower.* as well.

Comment 13 Adam Williamson 2012-03-02 21:33:53 UTC
let's bump the version a bit. David, anything?

Fedora Bugzappers volunteer triage team

Comment 14 David Zeuthen 2012-03-03 18:52:41 UTC
No, it doesn't make any sense to have some kind of "desktop admin" group so you can skip password dialogs - we tried it and it doesn't work [1]. The answer is really that the mechanism we ship should work out of the box, not that users should add themselves to some "admin" group to make their OS actually work. Hence, if you see useless password dialogs, just complain to the author of the mechanism that makes the password dialog appear.

The place to discuss this in upstream polkit is here


so I'm closing this as UPSTREAM. If you disagree, the place to discuss is in that upstream bug, not some downstream bugzilla.

[1] : we do have a 'wheel' group that is used to specify what "administrator authentication" means but that is different...

Comment 15 Tim Waugh 2012-03-05 13:15:21 UTC
Re-opening as this still affects Fedora.  The policy in cups-pk-helper was designed by following the Fedora rules (AFAIR drafted by adamw, I can't find them now) on what the default polkit policies for mechanisms should be.

If those rules are no longer correct, let's just change the cups-pk-helper policy and fix this bug.

Comment 16 Adam Williamson 2012-03-05 22:54:50 UTC
Tim: that policy proposal never made it out of draft, so you don't have to consider yourself to be bound by it. I certainly wouldn't; I'm no kind of security expert, I only ever drafted the policy as a starting point. It did get some discussion and refinement at the time, but I would still not invest any kind of confidence in it as a guideline, to be honest.

Fedora Bugzappers volunteer triage team

Comment 17 Valent Turkovic 2012-06-14 09:50:27 UTC
Created attachment 591796 [details]
Screenshot from "gnome-control-center printers" asking for password

Screenshot from "gnome-control-center printers" asking for password

Comment 18 Valent Turkovic 2012-06-14 09:54:15 UTC
This is still an issue on Fedora 16 and 17, is has been 2 years and this issue has still not been resolved, why?

Why are Administrator users being asked for root pasword when editing printer options?

I have been asked during the install and I choose to put my user in Administrator group (wheel) but I still get asked all the time to provide password.

if I'm not mistaken this is the same issue that Linus Torvalds vented regarding same issue on OpenSuse - https://plus.google.com/102150693225130002912/posts/1vyfmNCYpi5

There is an simple fix on Fedora wiki:

Create a pklocalauthority file called /etc/polkit-1/localauthority/50-local.d/10-printer-config.pkla with this content: 

[Desktop Administrator Permissions]

So why isn't this being done?

Comment 19 Valent Turkovic 2012-10-10 11:40:08 UTC
I'm using Fedora 17 with all latest patches and this is still an open bug. Is anybody working on this? It is trivial to fix.

Comment 20 Marek Kašík 2012-10-10 14:20:18 UTC
Hi Valent,

I've just tested this and polkit asks me for my (non-root) password when I'm in "wheel" group on Fedora 17 and Fedora 18.


Comment 21 Adam Williamson 2012-10-10 23:52:16 UTC
/usr/share/polkit-1/actions/org.opensuse.cupspkhelper.mechanism.policy does seem to require auth_admin for most CUPS actions, so it _looks_ like it ought to work. i'll take a look at it myself if I can find a minute. valent, exactly what reproduction procedure are you using here?

Comment 22 Valent Turkovic 2012-10-12 13:04:59 UTC
Looks like it works now. I'll try a few different things and report back.

Comment 23 Tim Waugh 2013-02-01 11:59:21 UTC
Seems to work OK in Fedora 18.  A user with account type 'Administrator' (I think this means 'in the wheel group'?) can add/modify/remove printers by providing their own password -- this is the same as is required for e.g. modifying the system time.

Comment 24 Marek Kašík 2013-04-23 15:03:04 UTC
(In reply to comment #22)
> Looks like it works now. I'll try a few different things and report back.

I'm closing this then.

Note You need to log in before you can comment on or make changes to this bug.