[systemd-devel] Need help to debug TAG-= rule

[Manuel Reimer]

Hello systemd-devel list,


according to the changelog of udev, it should be possible to clear TAGs
using "TAG-=" since systemd 217:

https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=v217#n70

But either I'm completely failing with using this, or there is still a
bug in systemd which renders this feature useless.


My distributor installs a udev rule file at
"/usr/lib/udev/rules.d/70-steam-input.rules" which contains:

    KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput",
TAG+="uaccess", OPTIONS+="static_node=uinput"

(don't ask why the OPTIONS+= is duplicated but that's what my
distributor installs)


I want to get rid of the 'TAG+="uaccess"' on my system but want to keep
all the other rules in this file without copying and editing it after
every update. So I created the folllowing as
"/etc/udev/rules.d/72-steam-security.rules":

KERNEL=="uinput", SUBSYSTEM=="misc", TAG-="uaccess"


But after rebooting my system I still have:

$ getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: root
user::rw-
user:manuel:rw-
group::---
mask::rw-
other::---

So I still get write access to the device which I don't want to have


I don't know at all how to dig into this. A first try was to use
"udevadm test /devices/virtual/misc/uinput" but this doesn't even
mention the "70-steam-input.rules" file.

I did try to just rename "70-steam-input.rules" to be sure it is
responsible for the "uaccess" tag to be set and it is. If the file is
renamed, then I no longer get unwanted write permissions.


Can someone please assist with finding the reason for this problem?


Thank you very much in advance


Manuel Reimer

[Andrei Borzenkov]

Post by Manuel Reimer
Hello systemd-devel list,
according to the changelog of udev, it should be possible to clear TAGs
https://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id=v217#n70
But either I'm completely failing with using this, or there is still a
bug in systemd which renders this feature useless.
My distributor installs a udev rule file at
    KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput",
TAG+="uaccess", OPTIONS+="static_node=uinput"
(don't ask why the OPTIONS+= is duplicated but that's what my
distributor installs)
I want to get rid of the 'TAG+="uaccess"' on my system but want to keep
all the other rules in this file without copying and editing it after
every update. So I created the folllowing as
KERNEL=="uinput", SUBSYSTEM=="misc", TAG-="uaccess"
$ getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: root
user::rw-
user:manuel:rw-
group::---
mask::rw-
other::---
So I still get write access to the device which I don't want to have
I don't know at all how to dig into this. A first try was to use
"udevadm test /devices/virtual/misc/uinput" but this doesn't even
mention the "70-steam-input.rules" file.

Is uinput module loaded at this point?

Post by Manuel Reimer
I did try to just rename "70-steam-input.rules" to be sure it is
responsible for the "uaccess" tag to be set and it is. If the file is
renamed, then I no longer get unwanted write permissions.
Can someone please assist with finding the reason for this problem?

udev commits option static_node using whatever settings for
user/group/tag are ON THE SAME LINE. It does not matter that you remove
tag later - udev already saw and processed

OPTIONS+="static_nodes=uinput", TAG+="uaccess"

and created /run/udev/static_node-tags/uaccess/uinput. It is not removed
when tag is removed.

Static nodes are processed literally line based - udev iterates over
each line. It is not obvious how to fix it - static nodes exist *before*
any device node appears, so you basically does not have anything to
attach permissions to.

udev tries to assign static node the same permissions as it would have
got on uevent, but instead of looking at final permissions it looks only
for one line.

This is src/udev/udev-rules.c:udev_rules_apply_static_dev_perms()

You should open issue on github so it can be tracked. Current
implementation is certainly questionable.