Fix USB device permissions without opening every device

Synopsis #

USB attachment and device permission are different events. A device can appear in usbconfig while its application-facing node remains unreadable to the login. A manual chmod is temporary because devfs recreates nodes after detach, reattach, and reboot.

Use the group and device-node policy documented by the driver or package whenever one exists. If a local devfs rule is necessary, match the narrowest application-facing node and grant only the required group. Do not make /dev/usb/*, /dev/ugen*, or all input devices world-writable.

Identify the failed layer #

List USB devices and recent attachment messages:

$ usbconfig list
$ dmesg | tail -100

Identify the kernel driver and the node opened by the application. Examples include a serial node under /dev/cuaU*, a camera node under /dev/video*, or an input node under /dev/input/. The raw ugen identity is not necessarily the node the application should open.

Inspect the node and the login’s groups:

$ ls -l /dev/device-node
$ id

Substitute the real node. Preserve the exact permission-denied message from the application. If the node does not exist, permissions are not yet the problem; return to driver attachment or the service that creates it.

Prefer an existing device policy #

Read the driver manual page and package documentation before inventing a group. Common policies include:

the webcamd group for nodes created by webcamd;
an application-specific group created by a package;
operator for administrative storage or virtualization workflows documented by FreeBSD;
games for game-controller event access documented by current HID drivers.

These groups can grant access beyond one device. Inspect the group’s purpose and existing devfs rules before adding a login:

$ pw groupshow groupname
# pw groupmod groupname -m loginname

Substitute the documented group and intended login. Start a new login session and verify with id; supplementary groups do not update inside existing sessions.

For cameras, follow the webcamd and cuse guide instead of adding a parallel raw-USB rule.

Understand persistent devfs configuration #

/etc/devfs.conf applies boot-time ownership and modes to devices available at boot. Its manual page explicitly directs hotplug devices to devfs.rules. USB device nodes can be destroyed and recreated, so a successful manual chown or chmod is only a diagnostic test.

A devfs ruleset has this structure:

[localrules=10]
add path 'device-node-pattern' mode 0660 group devicegroup

This is a template, not a literal rule. Replace both placeholders. The pattern is relative to /dev and should match only the required application-facing node class. Mode 0660 gives the owner and selected group read/write access without opening the node to every login.

Before using a wildcard, list every node it currently matches and consider devices that it could match later. A broad input/event* rule, for example, can expose keyboards as well as the intended controller.

Apply one local ruleset #

Inspect existing local definitions and the selected system ruleset:

# sed -n '1,240p' /etc/devfs.rules
$ sysrc devfs_system_ruleset

Merge the narrow rule into the existing locally named ruleset. Do not create a second ruleset with the same number or replace package-provided rules accidentally.

When localrules is the reviewed ruleset name, select it and reapply devfs configuration:

# sysrc devfs_system_ruleset=localrules
# service devfs restart

Recheck the node mode, then detach and reattach the USB device and check it again:

$ ls -l /dev/device-node

The reattachment test is important. A rule that works only for the current node instance is not a persistent hotplug policy.

Keep raw USB access exceptional #

Raw USB nodes can permit control transfers that exceed the application’s ordinary needs. Granting a desktop login access to every raw USB bus node broadens the effect of a compromised application or browser. Treat a project’s request for raw access as a security decision:

Confirm that no kernel driver exposes a narrower node.
Confirm the exact node pattern and required operations in upstream documentation.
Use a dedicated group with only the intended logins.
Avoid 0666 and blanket ugen* or usb/* rules.
Recheck the rule after adding new USB device classes to the system.

Storage permissions require additional caution. Allowing a login to write a raw disk can destroy filesystems, and allowing untrusted users to mount arbitrary filesystems creates a separate security boundary. Follow the FreeBSD storage chapter instead of generalizing a peripheral rule to disks.

Report useful evidence #

A permission report should include:

FreeBSD release and architecture;
usbconfig list entry and relevant attachment messages;
attached driver and application-facing node;
node owner, group, and mode before the change;
login groups from a fresh session;
the exact devfs rule and every path it matches;
the result after detach and reattach.

This evidence distinguishes a missing driver, an incorrect package policy, and an overly narrow or overly broad local rule.