π udev Rulesο
When Rules Are Checkedο
udev rules are checked every time a device event occurs β this includes when a device is added, removed, or changed. For most rules this means when you plug in hardware, but it also applies to virtual devices being registered by drivers at boot, like a keyboard backlight.
When an event fires, udev scans all rules files and applies every rule that matches β it doesnβt stop at the first match.
File Numberingο
Rules files are loaded from /etc/udev/rules.d/ (and a few other locations)
in strict numerical order based on the prefix. So 10-foo.rules is processed
before 90-bar.rules.
The number lets you control priority and ordering:
Low numbers (10β49) β early, often used by the system or distro
Mid numbers (50β74) β general purpose rules
High numbers (75β99) β late-stage overrides and user customisations
If two rules conflict, the last one applied wins, so higher-numbered files take
precedence. The convention of using 90- for local rules is deliberate β it
ensures your custom rules run after the distroβs defaults.
Anatomy of a Rule Lineο
Each line is a comma-separated list of key-operator-value triplets, split into two categories.
Match Keysο
Conditions that must be true for the rule to apply:
Key |
What it matches |
|---|---|
|
The device subsystem e.g. |
|
The kernel name of the device |
|
A sysfs attribute value of the device. For example, to match a USB device by vendor and product ID: SUBSYSTEM=="usb", ATTR{idVendor}=="046d", ATTR{idProduct}=="c52b"
|
|
A udev environment variable |
Assignment Keysο
Actions to take if all conditions match:
Key |
What it does |
|---|---|
|
Execute a command |
|
Set file permissions on the device node |
|
Set the owning user. Note: this only applies to |
|
Set the owning group |
|
Create a symlink to the device |
|
Rename the device node |
Operatorsο
Operator |
Meaning |
|---|---|
|
Match/compare |
|
Negative match |
|
Assign a value |
|
Append to a list |
A complete rule reads as: if all the match conditions are true, apply all the assignment actions.
Example: ThinkPad Keyboard Backlightο
The following rule grants all users write access to the ThinkPad keyboard
backlight brightness control. Because tpacpi::kbd_backlight is a sysfs
node rather than a /dev node, OWNER= cannot be used β instead
RUN+= calls chmod directly on the sysfs brightness file:
SUBSYSTEM=="leds", KERNEL=="tpacpi::kbd_backlight", RUN+="/bin/chmod a+w /sys/class/leds/%k/brightness"
The %k is a udev substitution variable that expands to the kernel name of
the matched device β in this case tpacpi::kbd_backlight.