FS#56818 - [cups][cups-filters] wrong group ownership
Attached to Project:
Arch Linux
Opened by Mantas Mikulėnas (grawity) - Friday, 22 December 2017, 06:35 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 01 December 2021, 15:27 GMT
Opened by Mantas Mikulėnas (grawity) - Friday, 22 December 2017, 06:35 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 01 December 2021, 15:27 GMT
|
Details
Currently the 'cups' and 'cups-filters' packages contain
files owned by the "lp" group.
However, the "lp" group has been moved to sysusers.d a while ago, and the GID on my system (good old 7) clearly no longer matches the GID on the build system (automatically allocated). As a result, my /etc/cups ends up with files owned by :systemd-coredump and such, just because they happen to have gid 999 etc. (Although the tarballs have both the username *and* the uid stored, pacman seems to always prefer the uid when extracting.) $ bsdtar --numeric-owner -tvf cups-filters-1.18.0-1-x86_64.pkg.tar.xz | grep etc/cups/ drwxr-xr-x 0 0 999 0 Dec 21 19:37 etc/cups/ -rw-r--r-- 0 0 999 26002 Dec 21 19:37 etc/cups/cups-browsed.conf $ bsdtar --numeric-owner -tvf cups-2.2.6-1-x86_64.pkg.tar.xz | grep etc/cups/ drwxr-xr-x 0 0 988 0 Nov 1 17:37 etc/cups/ -rw-r----- 0 0 988 6346 Nov 1 17:37 etc/cups/cupsd.conf drwxr-xr-x 0 0 988 0 Nov 1 17:37 etc/cups/ppd/ -rw-r----- 0 0 988 142 Nov 1 17:37 etc/cups/snmp.conf.default cups 2.2.6-1 cups-filters 1.18.0-1 |
This task depends upon
Closed by Andreas Radke (AndyRTR)
Wednesday, 01 December 2021, 15:27 GMT
Reason for closing: Fixed
Additional comments about closing: 2.4.0-3
Wednesday, 01 December 2021, 15:27 GMT
Reason for closing: Fixed
Additional comments about closing: 2.4.0-3
My suggestion is to either remove lp definition from basic and move it to cups package, or define our old gid of lp in basics.conf.
I'll add Christian to get his opinion on this.
tmpfiles.d could fix the ownership permissions as another alternative
Adding back the lp to filesystem is an option, but will make the definition of lp on 2 packages (filesystem, systemd) instead of 1 (systemd).
I sent an email to systemd mailing list to get their lights.
It would however lead to the pacman database storing incorrect ownership permissions.
Another solution would be pacman extracting based on names instead of ids but that is not an available option for now.
Shows some udev rule matches for lp /usr/lib/udev/rules.d/99-systemd.rules and /usr/lib/udev/rules.d/50-udev-default.rules
So to avoid splitting those rules out leaving lp in /usr/lib/sysusers.d/basic.conf seems easier.
What actually breaks if --with-cups-group=lp \ was dropped from https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cups#n69 ?
The group ownership as shipped is wrong but what does this actually stop cups from doing? The bug report does not indicate cups failing to operate in any way.
For more "man cupsd-conf", look for "group".
# Default user and group for filters/backends/helper programs; this cannot be
# any user or group that resolves to ID 0 for security reasons...
#User daemon
#Group lp
# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
SystemGroup sys root
Is that not the groups sys and root used for authentication and the group lp only used for calls to external executables?
Which would still be wrong if such an executable ever wanted to read one of cups config files.
Adjust configure to --with-cups-user=cups --with-cups-group=cups.
@Seblu: What's your preferred solution? When are you going to implement it? filesystem 2017.12-2 wasn't touched for this bug.
@Andreas:
Filesystem was not touched because the solution is not to find there; either in systemd or in cups.
I'm fine with both solution, although I have a preference for not patching systemd package to stick the lp gid because of cups.
If I understand correctly the «overengineered» solution proposed by loqs, it looks the easiest and cleanest:
- no systemd/filesystem update
- one sysusers files to create cups user/group and append cups to lp group (to manage direct attached printers)
- cups will not use the catch-all user «daemon» for its external program execution
I no objection, I'll move in that way soon.
agregory is working on this. libarchive supports a callback for resolving names to IDs at extraction time.
add a sysusers.d entry for the user / group cups with ID 209 lowest available GID/UID pair according to https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database
change ownership of /etc/cups from root:lp to root:cups
cups.patch:
replace --with-cups-user=daemon --with-cups-group=lp with --with-cups-user=cups --with-cups-group=cups
change ownership /etc/cups/ssl from root:lp to root:cups and the recursive chgrp of /etc/cups from lp to cups
One note on existing installs the directories /etc/cups /etc/cups/ssl and /etc/cups/ppd will not have their ownership changed as pacman does not change directory ownerships.
Edit:
The checksum for cups-filters.sysusers is a mismatch as I changed the ID from 200 to 209 in the patch but forgot to update the checksum.
I think we should add a post_install message to notice group change and suggest a chgrp run.
Do we agree that no user breakage are expected, as the cups is member of the lp group?
Is the maintainer ok with this?
otherwise it would need to be --with-cups-user=209 --with-cups-group=209. Agreed the intent is for no user breakage need testing to prove this is the case.
if [[ $(vercmp 2.2.6-2 $2) = 1 ]]; then
chgrp -R 209 /etc/cups
This is what I get this way after a reboot:
andyrtr@laptop64:/home/andyrtr $ ls -lha /etc/cups/
insgesamt 156K
drwxr-xr-x 4 root nobody 4,0K 14. Jan 21:10 .
drwxr-xr-x 91 root root 12K 14. Jan 21:10 ..
-rw------- 1 root nobody 0 14. Jan 20:58 classes.conf
-rw-r--r-- 1 root cups 26K 22. Aug 17:32 cups-browsed.conf
-rw-r--r-- 1 root cups 15K 10. Jun 2016 cups-browsed.conf.bak_20160610
-rw-r--r-- 1 root cups 26K 14. Jan 21:06 cups-browsed.conf.pacnew
-rw-r----- 1 root nobody 2,9K 14. Jan 20:58 cups-files.conf
-rw-r----- 1 root cups 2,9K 14. Jan 20:58 cups-files.conf.default
-rw-r----- 1 root nobody 4,5K 20. Sep 2016 cupsd.conf
-rw-r----- 1 root cups 2,9K 30. Jul 2008 cupsd.conf.bak
-rw-r----- 1 root cups 6,2K 14. Jan 20:58 cupsd.conf.default
-rw-r----- 1 root cups 6,2K 14. Jan 20:58 cupsd.conf.pacnew
drwxr-xr-x 2 root nobody 4,0K 14. Jan 21:10 ppd
-rw------- 1 root nobody 130 14. Jan 21:10 printers.conf
-rw------- 1 root cups 130 14. Jan 20:08 printers.conf.O
-rw-r----- 1 root cups 142 14. Jan 20:58 snmp.conf
-rw-r----- 1 root cups 142 14. Jan 20:58 snmp.conf.default
drwx------ 2 root nobody 4,0K 27. Apr 2016 ssl
-rw-r----- 1 root lp 113 14. Jan 21:10 subscriptions.conf
-rw-r----- 1 root cups 113 14. Jan 20:08 subscriptions.conf.O
I wonder why the cups directory itself is owned by nobody and some other files inside also.
Also the output of `id cups` please.
Also did you update the config file /etc/cups/files.conf if needed?
/dev/bus/usb/001/005
which I think is the device that cups needs to write to in order to print. It has owner "root.lp" and permissions 664.
crw-rw-r--+ 1 root lp 189, 4 Jan 22 20:49 /dev/bus/usb/001/005
So when cups is running with group cups it cannot write to this device. This is apparent already when trying to add the printer in the CUPS web interface. With cups in extra it finds the printer immediately and I can add it, with the one in testing I cannot. After running "sudo chown root.cups /dev/bus/usb/001/005" I can print again.
To answer your questions:
0) I think there is no error in /var/log/cups/error_log - it looks the same whether the print succeeds or not.
1) id cups prints: uid=209(cups) gid=209(cups) groups=209(cups),7(lp)
2) I didn't have to change ownership of any files in /etc/cups.
3) My /etc/cups/cups-files.conf is identical to /etc/cups/cups-files.conf.default.
u cups 209 "cups helper user"
m cups lp
The cups user is part of lp group. Are you sure you have systemctl reload daemon and restart the cups server? Btw. is this a parallel printer?
cups.debug2.4.txt Group lp User daemon daemon/cups-deviced
cups.debug2.5.txt Group 209 User 209 cgi-bin/admin.cgi
For admin.cgi cups uses the expected uid for cups-deviced it uses uid 0 which should still work (is it hard coded to not use uid 0?)
#!/bin/bash
id 2>&1 > /tmp/debug.txt
exec /usr/lib/cups/backend/usb.bin "$@"
# cat/tmp/debug.txt
uid=209(cups) gid=209(cups) groups=209(cups)
$ /usr/bin/id cups
uid=209(cups) gid=209(cups) groups=209(cups),7(lp)
So the usb driver as executed is only a member of the cups group
Thanks for the debugging loqs!
changed to the following sorry seems to work sorry no patch and code is dreadful but it seems to be targeting the right call now
if (!getuid() && user)
{
#include <pwd.h>
struct passwd * pwd = getpwuid(user);
if(initgroups(pwd->pw_name,pwd->pw_gid))
{
fprintf(stderr, "DEBUG: getpwuid failed\n");
exit(errno + 100);
}
setuid(user); /* Run as restricted user */
}
So far, my tests are good. It works without intervention on my setup after the first restart. Note that I use a remote printer via lpd.
However, two thoughts:
- We should use «--with-cups-user=cups» instead of «--with-cups-user=209» and «--with-cups-group=cups» instead of «--with-cups-group=209» in the configure. These values are used in «cups-files.conf» and are incorrect. Adding cups in makedepends would make this possible with the right uid/gid in the tarball.
- To not break setup with special user/group configuration, I would only changes group of files in /etc/cups when previous group was the default (lp) ; so use «find /etc/cups -group lp -exec chgrp cups {} \;» instead of «chgrp -R 209 /etc/cups».
Considering for a future CUPS release.
@seblu
"To not break setup with special user/group configuration, I would only changes group of files in /etc/cups when previous group was the default (lp)"
This way we omit users with already broken config. In my case files in /etc/cups were owned by libvirt group.
It's still hacky and I'd prefer a fixed "lp" guid but this is not intentional by systemd upstream. I guess we are really forced to workaround our pacman limitations here.
Have now tested printing successfully on this system from a local usb printer.
@loqs - you may want to send it to the upstream bug as well.
The 2.4.0 release introduces a major change here: https://github.com/OpenPrinting/cups/pull/274
The patch we use now breaks the build.
I'm going to upload 2.4.0 to testing with the patch disabled so assume the ownership breaking depending on your local setup.
Maybe someone is willing to fix our patch. @loqs?
But be aware the upcoming next major 3.0 release will drop all driver driven printing anyway. So I'm not sure if it's worth for now.
Is there any solution for printers that require a driver with 3.0?
[1] https://github.com/OpenPrinting/cups/commit/1867a90df897b838c996252aec98bb0d14fd10b4
For 3.0 and later check out upstream intention to either use driverless printers or use printer applications provided by the snap store. No further comment here. Feel free to bring this to our ml or better upstream.
See also https://openprinting.github.io/OpenPrinting-News-November-2021/