On Jan 17, 2014, at 6:31 PM, Ariel Wainer wrote:
> On 17/01/14 01:13, Charles Lepple wrote:
>>
>> Good point. I forgot that the permissions errors would happen after the
numeric device IDs were matched.
>>
>> I just pushed 3c13603. Tested by telling the driver to match a random
USB device instead of 0001:0000, and sure enough, when the driver didn't
have write access, the unpatched code crashed. Not sure I want to try and send
UPS polling commands to either a working UPS, or the mouse or keyboard, so
I'll leave the rest of the testing to you :-)
>
> I see that the commit belongs to the master branch :)
> It correctly informs there's a permission error now.
Oops, forgot to mention that it was merged. Once drivers start to work well
enough for testing, I like to merge them in sooner rather than later. If we need
to do any major refactoring, that would go on a branch temporarily.
>> scripts/udev/nut-usbups.rules should have an entry for 0001:0000
(although the comments mention a different driver). You may have to refresh udev
somehow to get it to fix the permissions on the UPS, although we have had
reports that the rules file silently fails on non-Debian-derived systems.
>>
>
> The rule in my config was:
>
> ATTR{idVendor}=="0001", ATTR{idProduct}=="0000",
MODE="664", GROUP="nobody"
>
> I have to add OWNER=nobody or change the mode to make it work, upsd is
> running under the user nobody, but I see all the rules looks the same,
> probably I'm doing something wrong.
Is that the working rule, or if not, which mode works? Also, what are the final
permissions?
The non-Debian udev problem seems to be that the entire rule was getting
skipped, but it sounds like this might be a more subtle permissions mismatch.
--
Charles Lepple
clepple at gmail