Bug#881619: /etc/cups/cups-files.conf: cannot job-edit as root: root missing from SystemGroup
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.browaeys@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
Reply to: