cups serial backend failed with Permission denied

Is this symptom still reproducible in 8.10?

Sorry we're no longer using a serial line for printing, so I'm unable to reproduce the problem, neither I could tell it's gone.

Since nobody else seems to have had similar problems, I think this bug can be closed.

Fixed in bzr, will upload soon.

cups (1.3.9-6) experimental; urgency=low

  [ Till Kamppeter ]
  * debian/local/filters/cpdftocps: The cpdftocps filter did case-sensitive
    checking for CUPS options to keep them away from the pstops filter. CUPS
    treats such options case-insensitive, so in some cases CUPS options got
    applied twice (LP: #299707).

  [ Martin Pitt ]
  * debian/rules: Install the serial backend with 0744 permissions to make it
    run as root, since /dev/ttyS* are root:dialout and thus not accessible as
    user "lp". Thanks to Chanoch (Ken) Bloom. (part of #506181, LP: #154277)

 -- Martin Pitt <email address hidden> Thu, 20 Nov 2008 13:43:27 +0100

Intrepid fix: http://bazaar.launchpad.net/~ubuntu-core-dev/cups/intrepid/revision/571

Accepted cups into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I tested the intrepid-proposed .debs on my wife's computer, and the serial backend appears now in "lpinfo -v" and detects printers.

This bug was fixed in the package cups - 1.3.9-2ubuntu3

---------------
cups (1.3.9-2ubuntu3) intrepid-proposed; urgency=low

  * debian/local/filters/pdf-filters/filter/pdftoraster.cxx: Fix include path
    of image.h, to fix FTBFS if libcupsimage-dev is not installed.

cups (1.3.9-2ubuntu2) intrepid-proposed; urgency=low

  [ Till Kamppeter ]
  * debian/local/filters/cpdftocps: The cpdftocps filter did case-sensitive
    checking for CUPS options to keep them away from the pstops filter. CUPS
    treats such options case-insensitive, so in some cases CUPS options got
    applied twice (LP: #299707).
  * debian/local/filters/pdf-filters/filter/pdftoraster.cxx: Fix handling of
    CMYK color space. Patch taken from upstream:
    http://svn.sourceforge.jp/view/pdftoraster/trunk/src/pdftoraster.cc?root=opfc&rev=850&r1=848&r2=850
    (LP: #294671)
  * debian/filters/pstopdf: Do not supply the margins from the PPD to the
    ps2pdf process, as this breaks full-bleed printing and is also disturbs
    the printing if PPDs have too conservative margin definitions. (LP: #282186)

  [ Martin Pitt ]
  * rootbackends-worldreadable.dpatch: Apply the same relaxed permission check
    to cups-deviced, so that backends installed as 0744 don't disappear from
    printer detecttion. This unbreaks the ipp/http and lpd detection.
    (LP: #275407, Debian #503644)
  * debian/rules: Install the serial backend with 0744 permissions to make it
    run as root, since /dev/ttyS* are root:dialout and thus not accessible as
    user "lp". Thanks to Chanoch (Ken) Bloom. (part of #506181, LP: #154277)
  * debian/control: Update Vcs-* for intrepid branch.

 -- Martin Pitt <email address hidden> Fri, 21 Nov 2008 13:13:14 +0100

Copied to intrepid-updates.

Are we going to see serial printing fix in hardy?

Kari,

yes, can do, but we need someone else than just me to verify the fix. Would you be up for testing a hardy-proposed update?

Martin Pitt kirjoitti:
> Kari,
>
> yes, can do, but we need someone else than just me to verify the fix.
> Would you be up for testing a hardy-proposed update?

Yes, I can test the update.

--
Kari Hanski
KH-Drive <email address hidden>
Rautapellonkatu 19
33700 Tampere, Finland 040-5456828

Fix uploaded to hardy-proposed queue, needs Steve to process.

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Accepted into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Serial printing seems to work now in hardy w proposed fix.
Thanks for quick response!

-kh

Copied to hardy-updates.

 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 i...

Hi Loye,

Loye Young [2008-12-10 19:02 -0000]:
> I can tolerate the "fix" as a stopgap, but alarms are going off in my
> head that it's a bad idea.

Your caution is appreciated, however, I'm afraid with cups all bets
are off already. At the moment, cups' idea of security is pretty
backwards, the central daemon which does the network configuration and
lots of parsing runs as root, while some backends which access the
hardware run as unprivileged user. So running the serial backend as
root doesn't really change attack vectors here, if you break cupsd,
you have root in either case. Thus the change in this bug seems
acceptable to me.

For the historians, we carried a huge patch to make cupsd run as
unprivileged system user, but it caused way too many problems, and
since the need for it keeps being neglected by upstream, we can't work
against that forever. We replaced it with a relatively tight AppArmor
profile.