1

I am trying to get my head around how udev rules are interpreted. Context: make a USB scanner accessible to myself as non-root user (I am part of the scanner group).

The following rule does not work:

SUBSYSTEM=="usb_device", ACTION=="add", ATTR{idVendor}=="04a9", ATTR{idProduct}=="190d", SYMLINK+="scan-canon", MODE="0666", OWNER="misha", GROUP="scanner"

However, the following rule DOES work:

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="canon_rules_end"

ATTR{idVendor}=="04a9", ATTR{idProduct}=="190d", SYMLINK+="scan-canon", MODE="0666", OWNER="misha", GROUP="scanner"

LABEL="canon_rules_end"

Surely the two versions are logically equivalent? I just can't figure out why the more elegant first version doesn't work. Any ideas?

1 Answer 1

0

After pulling out so much hair I figured it out.

It turns out the SUBSYSTEM for my scanner is actually usb. That's why the first version of the rule (the elegant one) fails - as it should, because SUBSYSTEM does not equal usb_device.

The second version works but for all the wrong reasons. Folks who do coding will be familiar with this insidious kind of self-inflicted bug. Udev applies AND logic to the specified conditions. That means, if either of the conditions evaluate to False, the GOTO won't be executed and the meat of the rule will get executed. Mixing negated conditions with AND logic is just nasty.

Anyway, now that I have fixed the first version, it works exactly as expected:

SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="04a9", ATTR{idProduct}=="190d", SYMLINK+="scan-canon", MODE="0666", OWNER="misha", GROUP="scanner"

EDIT: As ikrabbe points out, the two original versions were never logically equivalent.

2
  • 1
    Actually your rules weren't logically equivalent I assume ;) Is the Action parameter somewho usefull here? The rule seem to match if Action == "add" or Action != "add", at least for your GOTO line.
    – ikrabbe
    Commented Sep 12, 2015 at 17:28
  • @ikrabbe Yeah, they weren't logically equivalent. The GOTO version is flawed (example: if SUBSYSTEM was "scsi" and ACTION was "add" then the GOTO wouldn't execute and the meat of the rule would. The only thing that stopped all hell breaking loose is the idVendor/idProduct conditions).
    – misha256
    Commented Sep 12, 2015 at 21:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .