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

This bug is still around in current Feisty. Scott?

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?

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.

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

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?

Will do the workaround in libgphoto2.

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

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

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

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.

 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.

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