Support supplementary groups for filters/backends/helper programs

[loqs]

cups 2.2.6
In cups-files.conf

User cups
Group cups

user cups is also a member of the lp group to allow access to local devices.
However cups backends are called with only the uid and git set without setting the additional groups
so backends that are not executed as root such as the usb backend only have acess to group cups and not the additional group lp preventing the access of devices owned root:lp

Downstream bug report that lead to encountering this issue https://bugs.archlinux.org/task/56818#comment165778

Changing

cups/scheduler/util.c

Line 303 in 58c3683

setuid(user); /* Run as restricted user */

to

if (!getuid() && user)
{
#include <pwd.h>
  struct passwd * pwd = getpwuid(user);
  if(initgroups(pwd->pw_name,pwd->pw_gid))
  {
    fprintf(stderr, "DEBUG: initgroups failed\n");
    exit(errno + 100);
  }
  setuid(user); /* Run as restricted user */
}

Adds the additional groups the restricted user is a member of and allows the usb backend to find a new usb printer. No additional testing was done.
Can additional group support please be added for supplementary groups.

[michaelrsweet]

Considering for a future CUPS release.

[michaelrsweet]

scheduler/util.c is only used by the cupsd helper programs. Any group mapping needs to probably happen in cups-exec.c.

Anyways, the whole printer driver interface is deprecated, and we can't see adding more functionality here as the whole shebang is going to be dropped.

[loqs]

Thank you for responding to the request.
The current patch being used is https://git.archlinux.org/svntogit/packages.git/tree/trunk/guid.patch?h=packages/cups and covers cups-exec.c and util.c use. Both at the time appeared to be needed to cover printer detection, addition and actual printing.

Does the deprecation extend to all uses of the User and Group from cups-files.conf?

Will the initial issue still exist with 2.3.x and if so how would you recommend solving it.
The issue arose because the group lp may not have the same gid between build and execution systems.
You can see from the downstream bug report more details about why the additional group is being used.

[michaelrsweet]

@loqs Ultimately we don't know for sure whether the new cupsd (after 2.3.x) will depend on external programs, although this seems likely at least for security reasons. We can revisit pulling in the supplemental groups at that time, but right now we are not comfortable introducing it for drivers when those drivers are going away.

WRT the group ID being different between the build and execution systems (which IMHO is insane for a system group), since CUPS uses the group name the numeric value at build time should not matter. Use the name, not the ID, in any configuration files. And stick with a system group that is part of the OS install and consistent across systems, not a group that is created when a package is installed.