Return to Answer

added some more information retrieved after @StephenKitt 's comment

Source Link

edited Feb 19, 2024 at 11:19

A.B

39.5k
2
87
134

When this is managed using systemd at least two components play a role:

udevd tags eligible devices appearing on the system with TAG+="uaccess"

Empirically the list could be found with something like (systems that don't have /lib symlinked to /usr/lib should also search in /usr/lib/udev/rules.d):
```
grep -rw uaccess /etc/udev/rules.d /lib/udev/rules.d
```
Among other results, one can find a line for rfkill in /lib/udev/rules.d/70-uaccess.rules:
```
KERNEL=="rfkill", SUBSYSTEM=="misc", TAG+="uaccess"
```

logind tracks user seat changes (of course in addition to creation) and changes ACLs for devices previously tagged with uaccess when the user seat is active

For the little details: seat_set_active() -> seat_apply_acls() -> devnode_acl_all(), the later checks for the uaccess tag.

When this is managed using systemd at least two components play a role:

udevd tags eligible devices appearing on the system with TAG+="uaccess"

Empirically the list could be found with something like (systems that don't have /lib symlinked to /usr/lib should also search in /usr/lib/udev/rules.d):
```
grep -rw uaccess /etc/udev/rules.d /lib/udev/rules.d
```
Among other results, one can find a line for rfkill in /lib/udev/rules.d/70-uaccess.rules:
```
KERNEL=="rfkill", SUBSYSTEM=="misc", TAG+="uaccess"
```

logind tracks user seat changes (of course in addition to creation) and changes ACLs for devices previously tagged with uaccess when the user seat is active

For the little details: seat_set_active() -> seat_apply_acls() -> devnode_acl_all(), the later checks for the uaccess tag.

Source Link

answered Feb 19, 2024 at 8:00

A.B

39.5k
2
87
134

Modern Linux system ecosystems, probably when systemd based, can change the access rights of /dev entries when physically logged (ie: in front of the keyboard).

One can compare the ownership of /dev/rfkill. Exemple here on a Debian 12 system when looking with user having UID 1000 logged in a local (physical) session:

$ echo $UID
1000
$ getfacl -n /dev/rfkill
getfacl: Removing leading '/' from absolute path names
# file: dev/rfkill
# owner: 0
# group: 106
user::rw-
user:1000:rw-
group::rw-
mask::rw-
other::r--

So here the extra ACL gives owner access rights to the device file:

user:1000:rw-

If not at the part where the user is physically logged in (the sleep 5 gives the time to switch to a console with a login prompt), this ACL gets removed if it was present:

$ sleep 5; getfacl -n /dev/rfkill
getfacl: Removing leading '/' from absolute path names
# file: dev/rfkill
# owner: 0
# group: 106
user::rw-
group::rw-
mask::rw-
other::r--

As long as the linked kernel driver doesn't specifically restrict further access rights or ownership beyond the ACL on the device file, this works for the application using it without additional privileges.

Running (as root would be better but the result doesn't really change):

inotifywait -m -r -e attrib /dev

and switching twice, to a console with a login prompt and back, to get an idea, it's usually also done for:

audio-related files (/dev/snd/)
video-related files (/dev/dri/)
possibly some removable device files (eg: the target of /dev/cdrom ...)
KVM for virtualization (/dev/kvm)
probably other files I missed.

This might not reflect defaults, but gives an idea.

A quick search found this entry in systemd documentation's in Multi-Seat on Linux:

Note that logind manages ACLs on a number of device classes, to allow user code to access the device nodes attached to a seat as long as the user has an active session on it. This is mostly transparent to applications.