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
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
|
Details
Description:
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: [1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/cups#n71 [2] https://wiki.archlinux.org/index.php/User_talk:Lahwaacz#Parallel_ports |
This task depends upon
FS#40937?FS#40937is 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.
[3] https://wiki.archlinux.org/index.php/CUPS/Troubleshooting#Permission_issue
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.
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?
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.
[4] https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules#L48
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.
Dave?
Thank you for your input.