Comment 18 for bug 154277

 I can tolerate the "fix" as a stopgap, but alarms are going off in my head that it's a bad idea. ("Danger Will Robinson! Danger Will Robinson!") Giving the serial backend root privileges by default seems the *wrong* approach to me. I'm having a hard time accepting that the only way to solve this problem is to allow yet another process to run with root privileges.

(BTW -- This bug seems to be related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489975. )

CUPS seems to be a Lernaen Hydra when it comes to getting permissions right. Martin. more than anyone, has been working on cups permissions for a while now, and he's expressed frustration, too. I can understand why he and others might want to give the process root privileges and cross this bug off the list.

Yes, we can give EVERY process root privileges and that would make many things easier, but doing so will undo decades of work ensuring *nix systems stay secure. It will also be asking for trouble later. There is (almost) always a way to "get 'er done" without escalating privileges.

Theoretically, administering the printing system should be done by the lpadmin group and the actual printing should be done by the lp group. (At many (most?) sites, it makes sense to give lpadmin rights to most users, but in business / enterprise settings, that's NOT the right thing.) If lp or lpadmin need to print to the serial port, It should be possible to make them members of the dialout group and get it to work.

>Already tried to put the user lp (owner of serial backend process) into group dialout - with no success.

My reaction is similar to Martin's here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462149#29. If the user writing to /dev/ttyS0 is a member of the dialout group, that user has enough permission. Another user besides lp must be doing the work.

I note Anthony Gelberg's comments:
"This led me to suspect permissions, and sure enough, changing /dev/ttyS0
to 0666 worked. I didn't really understand this, as root had rw
permissions anyway. I had a glance at scheduler/cups-deviced.c, and
there is certainly some magic there relating to the user that it runs
the backend as. Unfortunately, I don't have time to delve deeper, but
see comments around line 204. "
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489975

Neither do I have the time to figure it out (even if I understood the code), but wag-and-a-poke debugging might do the trick. Before escalating the serial backend to root, the following solutions should be tested, in the listed order (maybe they have, but that should be documented somewhere):
1. adding the lp group to the dialout group,
2. adding the lpadmin group to the dialout group.
3. adding the lpadmin user to the dialout group.
(I don't have a serial printer handy, so I can't do it.)

I'm sensitive to the importance and complexity of getting printers configured and of setting device permissions work properly on a *nix system. A couple of years ago, I wrote to a colleague about my frustrations at how hard it was to set up a printer. https://lists.linux-foundation.org/pipermail/printing-summit/2006/000451.html. The ease of printing has come a long way in the three years since I first tried to set up a Unix printer, and that's a Good Thing (tm). We don't want to throw out the baby with the bathwater, however.

I know that (eventually) AppArmor, SELinux, and related solutions will provide additional security to the system, but such top-down security measures are no substitute for setting permissions properly at the device, process, and file levels. (I know, "devices are files." )

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.net