Created attachment 207110 [details]
buttons affected by the bug

Which exact GNOME version and distribution is this about?

GNOME 3.2 on Ubuntu 11.10

I would like to confirm this behaviour for about 5 months now. I am ready to test what ever you need to fix this.

My System:

Ubuntu 11.10 amd64
Gnome-Shell 3.2

with a brother network printer. But i am quite sure it happened with other network printers, too. I never tested a USB one and i don't have one..

Deleting print jobs through the cups webinterface does work.

Confirming on debian sid/experimental with custom gnome 3.3.x stack.
g-c-c is 3.3.90, cups 1.5.2, USB printer attached locally. 

Job-overview is showing correct values, but one can not pause/cancel jobs neither as normal user nor after gaining additional privileges. Cups webinterface works as expected.

confirming on ubuntu precise, gnome-control-center 3.3.90

Confirming on Ubuntu 12.04, Gnome shell, printer is a HP USB printer, removal succeeds via CLI and HPLIP GUI utility

Jeroen: Package version info welcome as I have no idea what Ubuntu 12.04 includes.

Hi Andre, specific packages besides gnome-control-center or just a complete dump?

Same problem here on Linux Mint 13 with a Epson DX3800.

Packages:
cups-1.5.3-0ubuntu4
cups-pk-helper-0.2.1.2-1
gnome-control-center-1:3.4.1-1linuxmint1

I found a work-around:

1. Open /etc/cups/cupsd.conf.

  sudo nano /etc/cups/cupsd.conf

2. There should be two instances of "JobPrivateValues default". Change them to "JobPrivateValues none". Save and close.

3. Then, restart cups:

  sudo restart cups

That's it. I have no idea, if this causes any security implications regarding whether a user can see/stop someone else's jobs, but I do not really care, because I am the only one using my system. @someone with background knowledge of cups-pk-helper/cups: please let us know, if this is a security risk.

I did a little bit of debugging and could track the issue down to this:

- gnome-control-center does everything right.

- cups-pk-helper fails in cups-pk-helper-0.2.1/src/cups.c near line 2238 in function cph_cups_job_get_status, when it retrieves the originating username of the job to stop:

  orig_user = _cph_cups_get_attribute_string (reply->attrs, IPP_TAG_JOB, attrs[0], IPP_TAG_NAME);

The result of _cph_cups_get_attribute_string is null. cups-pk-helper therefore thinks (as far as I understood) that the user requesting the stopping of the job is different from the user who submitted the job (orig_user) and does not continue to request from cupsd to stop the job.

- The result of the function _cph_cups_get_attribute_string comes from cupsd. The function makes a connection to cupsd and requests the value of "job-originating-user-name". cupsd returns nothing, though, because it considers this attribute to be "private" (I do not really understand, why it does not reveal it to cups-pk-helper). See file cups-1.5.3/scheduler/ipp.c near line 7466 in function get_job_attrs:

  exclude = cupsdGetPrivateAttrs(policy, con, printer, job->username);

The result of cupsdGetPrivateAttrs contains "job-originating-user-name". Therefore, it is "exclude"d from cupsd's answer to cups-pk-helper.

I do not know, whether this is something to be fixed on the side of cups-pk-helper or cups. I am not involved in any of these projects. Help anyone?

Confirming that your workaround works, at least for single user machines this shouldn't be harmful. Thank you for digging into it! Strange that this doesn't seem to be an issue with other cups frontends...

The workaround worked for me as well.

Ubuntu 12.10, Gnome-shell 3.4.1, HP Laserjet M1132MFP.
I'm the only user for this computer...

The problem should be fixed in cups-pk-helper-0.2.2 (and there were also some fixes related to user names in 0.2.3). Could you confirm that?

I can confirm this bug on GNOME 3.8 and cups-pk-helper-0.2.5, I'm running on Ubuntu GNOME 3.10.

I've sent a file to my network printer and I can't stop it from the jobs pending g-c-c's interface.

I've haven't check the work around described above. I'll do and report back.

AFAIR this feature have never work for me from GNOME 3.4, I've always use system-printer-config to do the job.

I've made the work around from Sebastian, and works for me too.

Are there any security implication about this?

Also facing the problem (OpenSuSe 13.2) cups-pk-helper is 0.2.5-4.1.4. Only root (cups-admin) can cancel jobs. The workround from Sebastian does not help here. Also changing the cups config to allow anyone to cancel jobs ("Erlaube Benutzern jeden Auftrag abzubrechen (nicht nur die Eigenen)" in the cups web-ui, does not have any effect.
Finally the error from the printer-queue UI (/usr/share/system-config-printer/system-config-printer.py) is not very helpful "There was an error during the CUPS operation: 'pkcancel'." - there is no tool called "pkcancel".

I think this is "system-config-printer" releated:

> id
uid=1001(john) gid=100(users) Gruppen=100(users),17(audio),33(video),40(games),490(pulse)

> lpq
Officejet_Pro_8600 is not ready
Rank    Owner   Job     File(s)                         Total Size
1st     john    124     TestJob                         99328 bytes

> cancel 124

> lpq
Officejet_Pro_8600 is not ready
no entries

Also from the localhost:631 the user can cancel the job (after logging in).

I'm seeing the same error here, with the following configuration:

  cups 1.7.5
  cups-pk-helper 0.2.5
  gnome-control-center 1:3.10.3

In this scenario, the aforementioned workaround works, but that's not an option in my case since it's not possible to know a priori how many users, nor who, are going to be using the computer.

What I also noticed, however, is that job can be cancelled in two alternative ways: using the CUPS web interface, or using system-config-printer (1.5.5)

I'm not very surprised about the web UI working, but it is indeed surprising that system-config-printer works while gnome-control-center doesn't. That somehow suggests the issue could actually be in how the client (g-c-c) interacts with CUPS and/or the PolKit helper, since s-c-p in theory does a similar thing: communicate with CUPS via the cups-pk-helper using D-Bus.

I'm investigating this issue at the moment, so I will come back if I find anything. In the meantime, if anyone can add some additional info/thoughts, it will be very much appreciated.

Also, related to the workaround, you don't need to set it to 'none' the value of JobPrivateValues, setting it to 'job-name job-originating-host-name phone' will be equally fine.

Reason is that the problem seems to be caused by the only one of the attributes that 'default' would translate into, according to the CUPS docs: job-originating-host-name attribute.

Thus, replacing 'default' for the explicit list of attributes it would be translated to minus the conflicting one is equally good, while probably not as bad as directly setting 'none'.

Ah, and you don't need to change the two instances of JobPrivateValues, only the one in the <Policy default> section (or at least that's what I've observed)

(In reply to Mario Sánchez Prada from comment #19)
> Reason is that the problem seems to be caused by the only one of the
> attributes that 'default' would translate into, according to the CUPS docs:
> job-originating-host-name attribute.
  ^^^^^^^^^^^^^^^^^^^^^^^^^
I meant, job-originating-user-name. That's the troublesome one

(In reply to Marek Kašík from comment #13)
> The problem should be fixed in cups-pk-helper-0.2.2 (and there were also
> some fixes related to user names in 0.2.3). Could you confirm that?

After debugging a bit more, I can confirm that I could reproduce exactly the same scenario described in Comment #10 with cups-pk-helper 0.2.5, and I'm not talking about the workaround part, but the later, which I'm quoting below:

> I did a little bit of debugging and could track the issue down to this:
> 
> - gnome-control-center does everything right.
> 
> - cups-pk-helper fails in cups-pk-helper-0.2.1/src/cups.c near line 2238 in
> function cph_cups_job_get_status, when it retrieves the originating username
> of the job to stop:
> 
>   orig_user = _cph_cups_get_attribute_string (reply->attrs, IPP_TAG_JOB,
> attrs[0], IPP_TAG_NAME);
> 
> The result of _cph_cups_get_attribute_string is null. cups-pk-helper
> therefore thinks (as far as I understood) that the user requesting the
> stopping of the job is different from the user who submitted the job
> (orig_user) and does not continue to request from cupsd to stop the job.
> 
> - The result of the function _cph_cups_get_attribute_string comes from
> cupsd. The function makes a connection to cupsd and requests the value of
> "job-originating-user-name". cupsd returns nothing, though, because it
> considers this attribute to be "private" (I do not really understand, why it
> does not reveal it to cups-pk-helper). See file cups-1.5.3/scheduler/ipp.c
> near line 7466 in function get_job_attrs:
> 
>   exclude = cupsdGetPrivateAttrs(policy, con, printer, job->username);
> 
> The result of cupsdGetPrivateAttrs contains "job-originating-user-name".
> Therefore, it is "exclude"d from cupsd's answer to cups-pk-helper.

It seems to me the problem is originated in CUPS, which I think it would be the right place to fix this since all cups-pk-helper does is to take whatever cph_cups_job_get_status() returns in cph_mechanism_job_cancel_purge() and use it to decide how to continue.

In this case, because CUPS is not working as expected with job-originating-user-name, cph_cups_job_get_status() returns CPH_JOB_STATUS_INVALID and stops, and I can't see how this could be fixed in cups-pk-helper, but I certainly could be missing a lot of things.

If someone has any insight, I'd certainly appreciate, otherwise I'll keep digging inside CUPS, see if I can see how to fix this.

(In reply to Sebastian Kums from comment #10)
> [...]
> - The result of the function _cph_cups_get_attribute_string comes from
> cupsd. The function makes a connection to cupsd and requests the value of
> "job-originating-user-name". cupsd returns nothing, though, because it
> considers this attribute to be "private" (I do not really understand, why it
> does not reveal it to cups-pk-helper). See file cups-1.5.3/scheduler/ipp.c
> near line 7466 in function get_job_attrs:
> 
>   exclude = cupsdGetPrivateAttrs(policy, con, printer, job->username);
> 
> The result of cupsdGetPrivateAttrs contains "job-originating-user-name".
> Therefore, it is "exclude"d from cupsd's answer to cups-pk-helper.
> 
So, it seems that the reason why CUPS considers this attribute private is because JobPrivateValues is set to default, which according to CUPS documentation  implies job-originating-user-name: https://www.cups.org/documentation.php/doc-1.7/ref-cupsd-conf.html

What I don't get yet is why this is working in Fedora, even if the CUPS configuration is set to the same default value...

It seems I found the problem (thanks Tim Waugh for your help), and why this is working in Fedora but not in Ubuntu, and seems to be a bug in the way debian packaged CUPS, which Ubuntu and others would have inherited:

First of all, when cups-pk-helper asks for the job-originating-user-name attribute to CUPS, such a value will only be returned if the user of the process requesting it is either the job owner or a "system" user, because JobPrivateAccess is set to default, which means @OWNER @SYSTEM according to the docs:

  https://www.cups.org/documentation.php/doc-1.7/ref-cupsd-conf.html

...and JobPrivateAccess is what controls who can access to the attributes set with JobPrivateValues, currently set to default too (thus implying job-originating-uer-name).

So, the problem here is that gnome-control-center does not cancel jobs directly as the running user (thus the owner of the jobs) but as the "root" user, because it always relies on the cups-pk-helper service instead: https://git.gnome.org/browse/gnome-control-center/tree/panels/printers/pp-utils.c#n3969.

Now, when cups-pk-helper asks CUPS for the job-originating-user-name attribute CUPS will know it's not the owner who requests it, but the root user. Thus, the only way CUPS will grant that other user access to the private attribute is, according to the value of JobPrivaveAccess (default), that the "root" user belongs to CUPS's system administration group, set by the SystemGroup directive in /etc/cups/cups-files.conf.

And here comes the difference between Fedora and Debian/Ubuntu: while Fedora defines SystemGroup as "sys root", Debian/Ubuntu defines it as "lpadmin". Therefore, that does not work in Debian/Ubuntu because cups-pk-helper is a D-Bus service run by root, while in Fedora it will work as a charm.

You can do a quick check by just adding root to SystemGroup in /etc/cups/cups-files.conf, and that should allow you to cancel jobs from gnome-control-center without having to change the defaults from JobPrivateValue.

I've checked Debian packaging and this seems to be an issue caused by how CUPS is packaged there. From debian/rules (either from Ubuntu trusty and debian unstable):

  override_dh_auto_configure:
  [...]
  dh_auto_configure -- \
          [...]
          --with-system-groups=lpadmin \
          [...]
          $(CONFIG_LIBUSB)

Not passing that --with-system-groups parameter, or at least adding "root" to it, would fix this problem, since then "root" would belong to SystemGroup and so gnome-control-center could cancel jobs via cups-pk-helper.

I've been checking the debian/changelog but still could not grasp why debian decided to leave lpadmin alone in SystemGroup, but it could be a bug indeed.

I'll comment on the Ubuntu bug associated to this issue to see what's their take on this, see if we can somehow report it to debian from there:
https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/934291

Hi Mario,

thank you very much for the investigation of the problem. I've started to looking at this from g-c-c's point of view since it seems that it is hard to fix this in cups-pk-helper.
I plan to check whether the cancellation succeeded and request the cancellation in g-c-c directly if it failed with cups-pk-helper. Unfortunately the cancellation request returns 'successful-ok' even if it was not successful and getting parameters of successfully cancelled job succeed :(.

(In reply to Marek Kašík from comment #24)
> ... and getting parameters of successfully cancelled job
> succeed :(.

which is of course correct, I have to request "job-state" attribute...

(In reply to Marek Kašík from comment #24)
> Hi Mario,
> 
> thank you very much for the investigation of the problem.

No problem, happy to help.

> I've started to looking at this from g-c-c's point of view since it seems
> that it is hard to fix this in cups-pk-helper.

Perhaps one way of fixing it in g-c-c could be to just skip cups-pk-helper altogether and simply using the CUPS API directly? I may very well saying suggesting total non-sense, as my knowledge of how g-c-c, cups-pk-helper and cups interact is fairly limited, but if that was possible then CUPS should not pose any impediment to g-c-c cancelling jobs since the UID of the process running g-c-c would match the @OWNER for the job being cancelled (although I'm assuming that g-c-c shows you only your own jobs, which I'm not 100% sure about).

I think that (skipping cups-pk-helper) is what system-config-printer does when interacting with jobs owner by the current user, so perhaps it's worth giving it a try.

> I plan to check whether the cancellation succeeded and request the
> cancellation in g-c-c directly if it failed with cups-pk-helper.
> Unfortunately the cancellation request returns 'successful-ok' even if it
> was not successful and getting parameters of successfully cancelled job
> succeed :(.

Yes, I saw that while playing with D-Bus API from cups-pk-helper directly from the terminal, and also got me quite confused for a while. 

Anyway, perhaps the right fix is just to make sure 'root' is part of CUPS's SystemGroup and forget about handling special cases from g-c-c for owned and not onwned jobs... that would imply changing the "lpadmin is the only user in SystemGroup" setting in Ubuntu/Debian, but perhaps that's right anyway? Actually, I fail to see why root could not belong to that group, but I might be missing something again and there's a good reason to do that, I don't know :/

*** Bug 730853 has been marked as a duplicate of this bug. ***

This is being fixed in cups-pk-helper after all, see https://bugs.launchpad.net/ubuntu/+source/cups-pk-helper/+bug/934291

Resolving as NOTGNOME