Permissions on /dev/usblp* don't agree with cupsys

Bug #76077 reported by Matt Zimmerman on 2006-12-17
Affects Status Importance Assigned to Milestone
libgphoto2 (Debian)
Fix Released
libgphoto2 (Ubuntu)
Martin Pitt
udev (Ubuntu)

Bug Description

Binary package hint: udev

/dev/usblp0 on my feisty system is 0660 root/plugdev, which results in cupsd not being able to write to it (cupsys : lpadmin lp dialout scanner ssl-cert). This is a regression from Edgy.

Related branches

Matt Zimmerman (mdz) wrote :

This bug is still around in current Feisty. Scott?

Steven Walter (stevenrwalter) wrote :

I just ran into this problem as well. My USB printer wouldn't work, I noticed "permission denied" in the logs.

I found something interesting in /etc/udev/rules.d/40-permissions.rules. Line 12 reads:

    SUBSYSTEMS=="usb", GROUP="plugdev"

Obviously, this puts all USB devices in the plugdev group. Further down on line 37, though ,we see:

    SUBSYSTEM=="usb", KERNEL=="lp[0-9]*", GROUP="lp"

The intention, obviously, is that USB printers be given the group lp instead. However, this is not happening. Is there some sort of incorrect assumption in the rules about the way they interact, or is udev improperly applying the rules?

Steven Walter (stevenrwalter) wrote :

I poked around at this some more, and found something interesting. If the "last_rule" option is added to the rule on line 37, the device node gets created with the correct group. This leads me to believe that some other rule later in the chain is overwriting the GROUP, however I was unable to find such a rule.

The attached patch causes the device node to be created with the correct group.

Patrice Vetsel (vetsel-patrice) wrote :

temporary workaround is to do :
sudo addgroup cupsys plugdev
sudo /etc/init.d/cupsys restart

Changed in udev:
importance: Undecided → High
status: Unconfirmed → Confirmed
Martin Pitt (pitti) wrote :

The cause is this line in 45-libgphoto2.rules:

ATTRS{idVendor}=="0000", ATTRS{idProduct}=="0000", MODE="0660", GROUP="plugdev"

Of course this is a bogus line and should be removed from the libgphoto2 rules, but still, this rule is not supposed to match on a printer with nonzero vendor/product IDs?

Martin Pitt (pitti) wrote :

Will do the workaround in libgphoto2.

Keeping udev task open, since this does not look right nevertheless.

Changed in libgphoto2:
assignee: nobody → pitti
importance: Undecided → High
status: Unconfirmed → In Progress
Martin Pitt (pitti) wrote :

Ah, got it. s/ATTRS/ATTR/ in the does the trick, since that won't catch parent devices without vendor/product ID.

Changed in udev:
status: Confirmed → Rejected

On Tue, Feb 13, 2007 at 02:03:57PM -0000, Patrice Vetsel wrote:
> temporary workaround is to do :
> sudo addgroup cupsys plugdev
> sudo /etc/init.d/cupsys restart

Please don't. If you are affected by this bug and require a workaround, do:

sudo chgrp lp /dev/usblp0

This must be done each time the printer is connected, but is less
risky than changing group membership (which defeats the security framework).

 - mdz

Martin Pitt (pitti) on 2007-02-13
Changed in libgphoto2:
status: In Progress → Fix Committed
Marcus Meissner (meissner) wrote :

This ATTRS line with two 0000 entries was caused by libgphoto2 2.3.1, which
had a small bug there.

I am using this patch, but please verify yourself.

Martin Pitt (pitti) wrote :

 libgphoto2 (2.3.0-0ubuntu2) feisty; urgency=low
   * packaging/generic/print-camera-list.c: Ignore zero vendor IDs, since they
     will match on parent devices without a vendor/product ID (since we have to
     use ATTRS, not just ATTR). This avoids messing up other device's
     permissions. (LP: #76077)
   * packaging/generic/check_ptp_camera: Run with bash, since the script has
     some bashisms that avoid calling cat several times. This makes the script
     work again. (LP: #67532)
   * debian/control: Adapt maintainers for Ubuntu.

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

Marcus, I just confirmed that your patch works as well. I will use it for the gutsy upload. Thank you!

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.