Arch Linux

Please read this before reporting a bug:

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!

FS#50009 - [cups] default 'lp' group for the package overlaps with device access

Attached to Project: Arch Linux
Opened by Ingo Albrecht (indigo) - Sunday, 10 July 2016, 14:01 GMT
Last edited by Andreas Radke (AndyRTR) - Thursday, 04 August 2016, 10:51 GMT
Task Type Support Request
Category Packages: Extra
Status Closed
Assigned To Andreas Radke (AndyRTR)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



cups is compiled with
--with-cups-user=daemon \
--with-cups-group=lp \

and /etc/cups-files.conf has options to change those. At the same time the 'sys' group is set in the conf file for the lpadmin rights (not compiled in with "--with_system_groups").

Are there known issues when using a cups-group other than lp?

The question came up working on the wiki on the instructions for Arch default groups. Some users do use other /dev/parport /dev/lp devices than printers.[2] In these cases, at least, it would be better to separate cups printing queue management for users from device access, if possible.

cups-files.conf(5) states: "Specifies the group name or ID that will be used when executing external programs. The default group is operating system specific but is usually "lp" or "nobody"."

Additional info:
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Thursday, 04 August 2016, 10:51 GMT
Reason for closing:  Won't fix
Comment by Andreas Radke (AndyRTR) - Tuesday, 12 July 2016, 15:45 GMT
Have you read this one:  FS#40937  ?
Comment by Ingo Albrecht (indigo) - Wednesday, 13 July 2016, 19:30 GMT
Thanks, no. I have now. Bad one. The issue/resolution of  FS#40937  is still described at [3].

Though, as far as I can see, it touches permissions, but not the question at hand. I opened this FS# so we don't come to troublesome conclusions for the wiki in [2].

Take the user who started our wiki-talk in [2]. He has a non-printer parallelport device and needs lp group assignment to access it. Now, if he ran cupsd with defaults, every user with lp group, has access to the non-printer device.

To remediate such, he can either:
(1) change udev for the non-printer device to apply a non-standard device group (other than lp), or
(2) change /etc/cups/cups-files.conf to use another Group for it.

Question 1: If he chooses (2), would this require another udev for the printer to apply the new custom group to the device or should it work without? (at least for generic ppd, nothing non-free)
Question 2: Which would you choose? :)

Thanks for your opinion.

Comment by Andreas Radke (AndyRTR) - Thursday, 14 July 2016, 10:04 GMT

That's where cups upstream defaults are set. Fedora doesn't change it. Debian set them lp:lp from their ChangeLog.
I wonder how they handle that parallel port device access? Any idea?

I couldn't find some discussion upstream. Most Google results are about no permission to access lp printers.

Personally I'd prefer users to use custom udev rules to use some e.g. "parallel" group if really necessary. But if you
want bring this question to the cups user or devel mailing list to get some opinion from Michael Sweet or Till Kampeter.
Comment by Jakub Klinkovsk√Ĺ (lahwaacz) - Thursday, 14 July 2016, 10:56 GMT
The udev rule assigning lp group to parport devices comes from systemd:

As far as I understand from [2], for each device connected to parallel port the system creates both /dev/parport0 and /dev/lp0 (possibly with different number), regardless if it is a printer or not. If that's true, it would be rather odd to let different groups access the same piece of hardware via different /dev nodes. Ideally udev should know if the attached device is a printer or not -- if it is, assign the lp group to both /dev/parport0 and /dev/lp0, otherwise use some different group. Is such distinction just a problem of the udev rule or is it technical limitation of the parallel port?
Comment by Andreas Radke (AndyRTR) - Thursday, 14 July 2016, 17:27 GMT
@Dave: any opinion?
Comment by Ingo Albrecht (indigo) - Thursday, 14 July 2016, 20:07 GMT
@AndyRTR: Thanks. I rather not bring it to a mailing list at this point, I don't have any parport devices myself.

I found a pointer for Lahwaacz' question: kernel doc/partport.txt states:
" * If you selected the IEEE 1284 support at compile time [Arch kernel does], you can say`lp=auto' on the kernel command line, and lp will create devices only for those ports that seem to have printers attached."

Which sounds like there is some sort of autodetection for (IEEE_1284 compatible) printers. If it works, it may in turn be possible to use that detection for identifying non-printer devices.

But I think we may go too far at that point:

Parport devices are deminishing, i.e. cases where users have a parport printer _and_ another parport device should be very limited.
More regular will be cases where users have a non-printer parport device _and_ a non-parport printer. The "group lp" problem remains, but it is easier to handle - if needed: override systemd's above quoted udev parport Group [4] with another and blacklist module lp.

Comment by Andreas Radke (AndyRTR) - Thursday, 28 July 2016, 06:16 GMT
Modifying the systemd udev rule file sounds like a reasonable way to handle that group conflict.

Sadly it's not under pacman backup control and users will need to change it on every systemd update. I'm not sure if we should put it under backup control
or if systemd upstream can change anything how parport group handling is done.

Comment by Andreas Radke (AndyRTR) - Wednesday, 03 August 2016, 14:48 GMT
I've seen someone added notes about lp group to our wiki pages. So can we close this one as "won't fix" ?
Comment by Ingo Albrecht (indigo) - Wednesday, 03 August 2016, 21:30 GMT
Yes, any changes to avoid the lp group conflict are best handled upstream, as you suggested earlier. We point to it and custom udev as work-around in the wiki.

Thank you for your input.