cups serial backend failed with Permission denied

Bug #154277 reported by Andreas Krause on 2007-10-19
12
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Undecided
Martin Pitt
Hardy
Undecided
Unassigned
Intrepid
Undecided
Martin Pitt
Jaunty
Undecided
Martin Pitt

Bug Description

Binary package hint: cupsys

In Gutsy Gibbon, a printer connected to the serial port /dev/ttyS0 doesn't work because of permission denied error.

$ cat /etc/cups/printers.conf
# Printer configuration file for CUPS v1.3.2
# Written by cupsd on 2007-10-19 11:08
<DefaultPrinter FS-1750>
Info Kyocera FS-1750
Location here
DeviceURI serial:/dev/ttyS0
State Idle
StateTime 1192784830
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
</Printer>

$ dmesg | grep ttyS0
[ 14.442083] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 14.443127] 00:0b: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

$ ls -al /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Oct 19 11:20 /dev/ttyS0

$ su - cupsys
$ cat > /dev/ttyS0
asdf
^D
_works_!

$ tail /var/log/cups/error_log
E [19/Oct/2007:11:36:15 +0200] [Job 15] Die Gerätdatei „/dev/ttyS0“ konnte nicht geöffnet werden: Permission denied
E [19/Oct/2007:11:36:15 +0200] PID 6221 (/usr/lib/cups/backend/serial) stopped with status 1!

It does not seem to be a AppArmor problem but an simple permission problem: After setting permissions of /dev/ttyS0 to 666 it works without any problem.

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

Any other ideas?

Daniel T Chen (crimsun) wrote :

Is this symptom still reproducible in 8.10?

Changed in cupsys:
status: New → Incomplete
Andreas Krause (andreas.krause) wrote :

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.

Martin Pitt (pitti) wrote :

Fixed in bzr, will upload soon.

Changed in cupsys:
assignee: nobody → pitti
status: Incomplete → Fix Committed
Martin Pitt (pitti) on 2008-11-20
Changed in cupsys:
assignee: nobody → pitti
status: New → In Progress
Martin Pitt (pitti) wrote :

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

Changed in cupsys:
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :
Changed in cupsys:
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

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!

Martin Pitt (pitti) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in cups:
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

Copied to intrepid-updates.

Kari Hanski (kh-khdrive) wrote :

Are we going to see serial printing fix in hardy?

Martin Pitt (pitti) wrote :

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

Martin Pitt (pitti) wrote :

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

Changed in cups:
status: New → In Progress
Steve Langasek (vorlon) wrote :

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!

Steve Langasek (vorlon) wrote :

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!

Changed in cups:
status: In Progress → Fix Committed
Kari Hanski (kh-khdrive) wrote :

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

-kh

Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in cups:
status: Fix Committed → Fix Released
Loye Young (loyeyoung) wrote :
Download full text (3.6 KiB)

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

Read more...

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.