The links points to weird findings. Does cups-pk-helper let one deletes jobs from other users ? gnome-control-center does not show jobs from other users. So I cannot see how could we guess we can delete their jobs from there.
Running cups-pk-helper as lpadmin will also fix the issue. >From cups point of view, SystemGroup is "root" access. We forbid the "root" account from managing jobs. But we let cups-pk- helper have SystemGroup access. Here is my old attempt to do what was suggested by the links, ie run the cups api call as calling user, not root. I now believe cups-pk- helper aims is to manage accesses to cups. Running it out of SystemGroup is against its purpose. NB: this patch is pretty lame. It only copes with default JobPrivateValues cups setting value. When admin change this setting it will break. Managing this grew out of bounds and I went back adding root to SystemGroup :) >From 94f985ffdc902b4b35cef1dd5dac967c8e49f49c Mon Sep 17 00:00:00 2001 From: Alban Browaeys <alban.browa...@gmail.com> Date: Tue, 19 Sep 2017 16:10:30 +0200 Subject: [PATCH] Fix job status always set to invalid with cups 1.5 and forward Set requesting user on job status request. This since job-originating-user-name is JobPrivateValues since cups 1.5.0 with default JobPrivateValues cupsd.conf policy. Set it to cups-pk-helper caller. The cups-pk-helper cupsUser is root while only the job owner has access to this attribute now. --- src/cups.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cups.c b/src/cups.c index a2cb9f4..e39fe56 100644 --- a/src/cups.c +++ b/src/cups.c @@ -2968,7 +2968,7 @@ cph_cups_job_get_status (CphCups *cups, /* Request attributes explicitly as the user running the process (as * opposed to the user doing the dbus call). This is root in general, * so we'll be authorized to get attributes for all jobs. */ - _cph_cups_add_requesting_user_name (request, NULL); + _cph_cups_add_requesting_user_name (request, user); resource_char = _cph_cups_get_resource (CPH_RESOURCE_ROOT); reply = cupsDoRequest (cups->priv->connection, -- 2.14.1 Le mardi 14 novembre 2017 à 19:08 +0100, Didier 'OdyX' Raboud a écrit : > Control: tags -1 +wontfix > > Le lundi, 13 novembre 2017, 15.34:25 h CET Alban Browaeys a écrit : > > per the man page root should be in cups-files.conf SystemGroup. > > JobPrivateAccess requires @SYSTEM or @OWNER but root in not in any > > of > > those. Thus root cannot job-edit (cancel jobs) > > This forbid cups-pk-helper from cancelling jobs as it run as root. > > > > A workaround is adding "root" to "SystemGroup" (which includes > > only lpadmin on debian). > > This was discussed last year: > https://lists.debian.org/debian-printing/2016/11/msg00045.html > > > In other words, letting cups-pk-helper run as 'root' (but accept > > commands > > from any allowed users) leads to a user-to-lpadmin privilege > > escalation. At > > least, it defers access control away from CUPS to cups-pk-helper. > > See also > https://bugs.debian.org/698504 > https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/ > +bug/934291 > > The point is that we don't want to let anyone with access to cups-pk- > helper > delete jobs through it as that defeats the security mechanism put in > place by > CUPS. > > The solution is to get cups-pk-helper run as root but use the > requesting user > when using the CUPS API (so that it respects the "system group" > restrictions > of CUPS). In other words, I think this is a bug in how cups-pk-helper > runs in > Debian. > > Cheers, > OdyX