Sane-backends installs libsane.rules as 70-libsane.rules so it is processed by udev after 40-hplip.rules or 55-hpmud.rules which are provided by hplip. The hplip rule sets the group of the usb device to lp afterwards the sane rule changes it's group to scanner. This causes problems for hplip's usb all-in-one devices as the owner needs to be lp in order to print and scan. I took a look at the sane rules but found nothing obvious which could cause the permission change as no rule seems to match. I am not an udev expert thus I CC'ed udev-bugs. This bug is somehow related to bug #197726, where the hplip permissions were overwritten by 65-permissions.rules from udev (changing the group from lp to usb). This file is not installed by udev anymore so I removed 70-hplip.rules (which zzam attached to this bug) from the hplip ebuild. Now a similar conflict occurs again with sane-backends. Re-adding this file will probably fix this again but it seems more a problem with the sane-backends rule file which should not mess with the rules set by hplip.
After a bit of messing around I have the following: In my home directory I can write to a 0664 file which is in the scanner group I can write to a file with the same permissions in /dev/bus/usb/005, however it does not have the c prefix in the stickybits like the device files do. I am definitely in the scanner group I am definitely in the lp group I cannot print when /dev/bus/usb/005/005 is in the scanner group I can print when /dev/bus/usb/005/005 is in the lp group. I can print when /dev/bus/usb/005/005 is set to chmod a+rwx Confounding I know...by me being in the scanner group, I would have thought this would allow me to write to the device if its sticky bits are set to 0664, and the file was in the scanner group. This is however not the case. This makes me think that any edit to /etc/udev/rules.d/xx-libsane.rules is simply a workaround. I am thinking the bug is in HPLIP. Thanks ubiquitous1980
Some more information from the gentoo-user thread where this all started. the complete thread is at [1]. > I have found the line which is at fault in xx-libsane.rules. Problem > is, what we are doing is a work around: > > # Hewlett-Packard Photosmart C5100 series > ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="5811", MODE="0664", > GROUP="lp", ENV$ > > I have changed the group to lp from scanner so that I could maintain the > file number. Problem is, if we have MODE="0664", those in the scanner > group should be able to access the printer. Do you think this suggests > a deeper bug? I created a testfile in my home directory with stickybits > set to 0664. I then set ownership to root:scanner. Of course, I could > edit the file, as I am in the scanner group. This makes me wonder why > the rules did not apply in /dev/bus/usb/005/005 when this file was set > to 0664 and group to scanner. I know for sure that the group was > scanner, but I cannot be sure that the file was truly set to 0664. > > For now I have the intra-config file workaround. I will see if I can > mess with things a bit to get things working. Here follows my answer to this post, which I already sent to the mailing list. Now I recognized that I sent it from the wrong mail-account so it did not go through: > I have found the line which is at fault in xx-libsane.rules. Problem > is, what we are doing is a work around: > > # Hewlett-Packard Photosmart C5100 series > ATTRS{idVendor}=="03f0", ATTRS{idProduct}=="5811", MODE="0664", > GROUP="lp", ENV$ I do not have such a line in my 70-libsane.rules. Problem is that this file is generated at compile-time so it probably detects your C5180 when sane-backends are installed. Can you attach your 70-libsane.rules. Can you also try to unplug your C5180 (power und usb), recompile sane-backends and see if you still have this line in 70-libsane.rules. I don't think this is a hplip bug. 70-libsane.rules is auto-generated at compile-time. It is called libsane.rules. The ebuild installs it under the name 70-libsane.rules. So the problem is either the number of libsane.rules is to high or even better the automatic detection should not mess with HP All-in-one products at all. If the number is lower or there is no line in the rules matching your product the device will finally be in the lp group. If I remember right you are able to print and scan if the device group is lp. [1] http://archives.gentoo.org/gentoo-user/msg_ae72c4933459ff1096654fe664a50f96.xml
Created attachment 230559 [details] 70-libsane.rules renamed to 39-libsane.rules Sorry I am late. Have been plenty busy with Uni.
Since I would prefer not to mess with the SANE udev rules generator if I can avoid it, I have renamed the rules file as you suggested in sane-backends-1.0.21. If this is a hplip bug: Printing team, do you want to take this one?
(In reply to comment #3) > Created an attachment (id=230559) [details] > 70-libsane.rules renamed to 39-libsane.rules > > Sorry I am late. Have been plenty busy with Uni. > Okay I was not able to see the rules which are causing this because I just did a "./configure && make && make install" and took a look at the rules file it generated. After installing sane-backends from the ebuild without setting a specific backend I get exactly the same rules file as yours with the entries for the hplip products which are overwriting the hplip rule file with wrong device permissions.
(In reply to comment #4) > Since I would prefer not to mess with the SANE udev rules generator if I can > avoid it, I have renamed the rules file as you suggested in > sane-backends-1.0.21. > If this is a hplip bug: Printing team, do you want to take this one? > Patrick thanks for the fix. Btw, I am pretty much the sole hplip maintainer. I think it is a sane-backends bug as it should not mess with HP All-In-One devices, because the hplip rules files take care of it. The only drawback I could think of is if someone wants to use a HP product which is able to scan without the hplip package if this is possible but I guess this is a corner case. But as sane-backends does not give any number to the libsane.rules file I think it is up to the packager to install it with a proper number so it fits into the distribution. This is what you already did. When looking at this bug from that perspective I would call the bug already fixed.
Well... why not? Please re-open if you don't agree.
