Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#60271 - [cups] Compiled with bad default user set to NFS 'nobody'

Attached to Project: Arch Linux
Opened by David Ford (FirefighterBlu3) - Monday, 01 October 2018, 18:10 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 12 April 2019, 09:35 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

PKGBUILD for cups uses "configure --with-cups-user=209 ..." (and for group), the configure script for cups sets to one of $ID (or lp, lpd, guest, daemon, nobody) on the building system. It appears that none of these are found on the build system, as the CUPS_USER and therefore CUPS_DEFAULT_USER are set to the NFS nobody uid of 65534.

cups default getpwnam(user) is compiled in and cannot change at runtime. userid changes in the system require recompilation or adding a different username to the system.

The end result is that unless CUPS_USER is specifically set in cups-files.conf, cupsd attempts to launch cgis with -u 65534, which is probably a bad uid on most modern systems which results in a segfault.

Therefore, anytime systemd changes userids, Arch, or an administrator changes userids, when related to the compiled in values, cups needs to be recompiled and re-released. The uid 209 doesn't exist on my up to date system. FWIW, hardcoding "209" instead of a username is probably a bad idea too.

Additional info:
* package version(s)
2.2.8-3

* config and/or log files etc.

reference: cups/scheduler/conf.c

Steps to reproduce:
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Friday, 12 April 2019, 09:35 GMT
Reason for closing:  Works for me
Comment by Doug Newgard (Scimmia) - Thursday, 04 October 2018, 15:58 GMT
So the issue here is that the user doesn't exist *at build time*?
Comment by Jensen McKenzie (your_doomsday) - Thursday, 04 October 2018, 17:05 GMT
"The end result is that unless CUPS_USER is specifically set in cups-files.conf, cupsd attempts to launch cgis with -u 65534, which is probably a bad uid on most modern systems which results in a segfault."

As you mentioned earlier "65534" maps to "nobody" so it's a valid uid.Also CUPS_USER is specified in cups-files.conf currently.

"The uid 209 doesn't exist on my up to date system. FWIW, hardcoding "209" instead of a username is probably a bad idea too."

The uid "209" is mapped to "cups" and created by /usr/lib/sysusers.d/cups.conf which is part of cups package.

Do you mean the problem is that cups will break if you change CUPS_USER in cups-files.conf? I'm not sure if this is supported case by Arch.
Comment by loqs (loqs) - Thursday, 04 October 2018, 17:12 GMT
Is there some other user or group using 209 or bad /etc/passwd /etc/group content that is causing systemd-sysusers to fail?
Comment by Andreas Radke (AndyRTR) - Saturday, 06 October 2018, 17:27 GMT
Check  FS#56818  and  FS#57041 . The user should be present when using an Arch system and a clean chroot.
Comment by Andreas Radke (AndyRTR) - Wednesday, 30 January 2019, 11:44 GMT
/etc/cups/cups-files.conf and /etc/cups/cups-files.conf.default both have "User 209" and "Group 209" properly set in my clean build chroot and must not be changed by yourself.
No idea what's happening on your system at runtime. Works for me.

Loading...