Created attachment 546200 [details]
screenshot of xfce dialog asking for root's password.

I already wrote in
https://bugzilla.novell.com/show_bug.cgi?id=827196#c1

The Bugzilla component Printing is primarily meant for the
base printing system (CUPS and printer driver packages)
but not for user application programs that provide
printing related functionality, compare its matching
Printing development project in the openSUSE build service
https://build.opensuse.org/project/show?project=Printing

I guess it does not depend on the platform
but happens on "all" platforms.


I cannot help here because I don't know what the
XFCE desktop does when cancelling print jobs.

FYI:
In general a normal user "foo" should be not allowed
by default to cancel print jobs of user "bar".
By default a normal usuer should be only allowed
to cancel his own print jobs.

That is system-config-printer, nothing to do with Xfce.

Should we change the component to xfce or to gnome?

I see some changes in the email from bugzilla that I did not do myself - but the email says _I_ did:

Carlos Robinson <...@opensuse.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|GNOME                       |Printing
           Platform|All                         |Other
           Found By|Community User              |---
         OS/Version|openSUSE 12.3               |Other

I must emphatically say that I did not change ANY of that! It is the second time such a disaster happens! :-/

Reverting.

This bug and the one I filed 827196 are probably related to bnc#752454 as indicated by Johannes Meixner. Since you can change printers with the KDE print module, ie use a ppd file, then there is a vulnerability of some sort.

Here is how I see things:

Just remove the ability to add printers via kde module or whatever printer settings gui you prefer and let users manipulate everything else without password of any kind.

So you would have (2) seperate settings:

1) add a printer (root password)
2) configure printers --- anybody or any group type security.

Clarification: I'm not using any KDE thing.

I can Cancel as user jobs I have initiated with the same user, using the cups web interface, or via "lprm JOBNUM" as user. However, XFCE asks for ROOT's password to do the same (presumably using Gnome print dialog). I don't know if once or twice, once is bad enough.

Ie, the desktop is not honouring cups settings. Even if the design decision is not to honour them, root password is excessive.

FYI:
Regarding different behaviour when CUPS is used
versus when Gnome print stuff is used, have a look at
https://bugzilla.novell.com/show_bug.cgi?id=749451#c8
and the subsequent comments therein.

(In reply to comment #8)
> FYI:
> Regarding different behaviour when CUPS is used
> versus when Gnome print stuff is used, have a look at
> https://bugzilla.novell.com/show_bug.cgi?id=749451#c8
> and the subsequent comments therein.

Please note that Bugzilla is about "Adding a new printer", whereas this one is about a user cancelling his own job. This can be done by the user using CUPS CLI or HTTP, but not via gnome/xfce print interface.

(In reply to comment #5)
> I see some changes in the email from bugzilla that I did not do myself - but
> the email says _I_ did:
...
> Reverting.

This is Bug 828779 - Firefox refresh badly on Bugzilla

My comment#8 was meant to point out that
there are different sets of policies used here, see
https://bugzilla.novell.com/show_bug.cgi?id=749451#c9

This means:

When you do something using CUPS directly (e.g. CUPS command
line tools or the CUPS web interface or using applictions that
work in full compliance with CUPS), then CUPS' own policies
(the so called "CUPS Operation Policies") are used as described in
http://www.cups.org/documentation.php/doc-1.5/policies.html

In contrast when you use Gnome printing tools, then the
Gnome policies are used "which are defined the policykit way"
and the "PolicyKit settings are controlled by polkit-default-privs
(and set_polkit_default_privs, that applies the defined policies)", see
https://bugzilla.novell.com/show_bug.cgi?id=749451#c9 and
https://bugzilla.novell.com/show_bug.cgi?id=749451#c12

As a result you can cancel your own print jobs when using
CUPS directly but not when using Gnome printing tools.

In the end this issue here is exactly an example of what
https://bugzilla.novell.com/show_bug.cgi?id=749451#c8
and the subsequent comments there describe in general.

Accordingly I change the subject of this issue here
from "XFCE desktop ask for root password to cancel user print jobs"
to "Gnome printing policies are not in compliance with CUPS policies"

Acording to
https://bugzilla.novell.com/show_bug.cgi?id=749451#c9
the difference in policies is intentional because Gnome wants
"to offer a consistent way to define policies on the machine".

Therefore - from my current point of view - it seems the bug here
is no bug but intentional so that it could be closed as "invalid".

But I am not involved in Gnome so that I leave it for the Gnome people
to actually decide what to do here.

I see, I understand.

But my original point still stands: it is not acceptable that Gnome asks for the root password to cancel your own print job.

I can accept that CUPS and Gnome printer/print policies be different. I can accept that you need root password to add/remove/configure a printer. But I can not accept that you need root password to cancel your own job!

Imagine a business environment, that you send a 1000 page doc to the printer on error, want to cancel it, and then you need to locate the admin to cancel it!

Absurd, no?

Well... I propose that the original title or this report be reinstated (or equivalent):

XFCE/Gnome desktop asks for root password to cancel user print jobs.

(xfce uses gnome print module)

Thanks for your clarification!
I agree.

I even think that the default Gnome printing policies
should match the default CUPS Operation Policies.

(In reply to comment #13)
> Thanks for your clarification!
> I agree.

Welcome and thanks, too.

> I even think that the default Gnome printing policies
> should match the default CUPS Operation Policies.

Me too... but I have no say in the matter.

It was reported that this is still a valid issue in Tumbleweed 201607xx

this is actually a ticket for the sec team, as it is about the default polkit privileges

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

(In reply to Dominique Leuenberger from comment #16)
> this is actually a ticket for the sec team, as it is about the default
> polkit privileges
> 
> 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


What does that actually mean? Do you want us to whitelist these
or having certain polkit actions set to "auth_self"? (Which could
be the case judging from the tilte).

(In reply to Sebastian Krahmer from comment #17)
> What does that actually mean? Do you want us to whitelist these
> or having certain polkit actions set to "auth_self"? (Which could
> be the case judging from the tilte).

Those are the settings as are currently shipped in polkit-default-privs.

The request of OP was to align those as closely as possible to the actually configured permissions in cups itself, allowing the user to perrform the action (I'd even say 'yes' instead of 'auth_self' - cups also does not ask)

The bare minimum should be

# User does not require root permission to modify his own print jobs
  org.opensuse.cupspkhelper.mechanism.job-edit yes

(In reply to Dominique Leuenberger from comment #18)
> (In reply to Sebastian Krahmer from comment #17)
> > What does that actually mean? Do you want us to whitelist these
> > or having certain polkit actions set to "auth_self"? (Which could
> > be the case judging from the tilte).
> 
> Those are the settings as are currently shipped in polkit-default-privs.
> 
> The request of OP was to align those as closely as possible to the actually
> configured permissions in cups itself, allowing the user to perrform the
> action (I'd even say 'yes' instead of 'auth_self' - cups also does not ask)
> 
> The bare minimum should be
> 
> # User does not require root permission to modify his own print jobs
>   org.opensuse.cupspkhelper.mechanism.job-edit yes

OK. I relaxed this one in the git. Its the only action that has "yes"
in upstream, so we are aligned with that.
The other polkit actions may be too dangerous (setting cupsd options etc).

Do you need new polkit-default-privs packages, or is it sufficient
to have it in git (and floating to Factory later)?

(In reply to Sebastian Krahmer from comment #19)
> OK. I relaxed this one in the git. Its the only action that has "yes"
> in upstream, so we are aligned with that.
> The other polkit actions may be too dangerous (setting cupsd options etc).

Thank you
 
> Do you need new polkit-default-privs packages, or is it sufficient
> to have it in git (and floating to Factory later)?

This bug has been open for 4 years - so a bit more or less probably won't make a huge difference; of course if the next loat to Factory is only in a year, it might be better to push it now.

submitted as sr#505040
should be available soon, closing bug

This is an autogenerated message for OBS integration:
This bug (827331) was mentioned in
https://build.opensuse.org/request/show/505041 Factory / polkit-default-privs