Fedora Silverblue (OSTree) | uinput input method stops working after the first time

[quazar-omega]

I have followed the guide and added myself to the uinput group:

$ groups
<username> wheel uinput

^{(where \<username> is the group corresponding to the username)} The udev rule is there:

$ cat /etc/udev/rules.d/60-weylus.rules
KERNEL=="uinput", MODE="0660", GROUP="uinput", OPTIONS+="static_node=uinput"

The first time I logged out, started the application and it was working, now, assuming I can just open the app and start it, I always face this issue:

ERROR weylus::websocket: Failed to create uinput device: CError: code: 101 message: error: failed to open /dev/uinput

Am I just missing a step? If it matters I'm using Wayland

[ghost]

Check the group permission on /dev/uinput with ls -la /dev/uinput.

For me the right group wasn't uinput, but input:

crw-rw---- 1 root input 10, 223 11. Feb 11:41 /dev/uinput

I had to change the udev rule to:

KERNEL=="uinput", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput"

[quazar-omega]

That is true

$ ls -la /dev/uinput
crw-rw----. 1 root input 10, 223 Feb 15 15:08 /dev/uinput

I edited the rule as you said:

$ cat /etc/udev/rules.d/60-weylus.rules 
KERNEL=="uinput", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput"

then I tried adding myself to the input group accordingly:

$ sudo usermod -aG input $USER

but it doesn't seem to work because the output of groups is still this:

$ groups 
<username> wheel uinput

Then I thought that it may be related to being on Fedora Silverblue, so I searched around and found out the reason this wasn't working in this Endless OS discussion, Endless uses OSTree as well and so the (slightly adjusted) solution given applies to Silverblue and it indeed worked perfectly:

1. retrieve input group in your /lib/group and append it to the end of /etc/groups:

   $ grep input /lib/group | sudo tee -a /etc/groups

2. add yourself to the input group

   $ sudo usermod -aG input $USER

3. reboot

Thanks a lot for giving me the piece I was missing to try and solve this!

[quazar-omega]

Maybe this could be added to the documentation now that I think about it, should I open a pull request?

[ghost]

@quazar-omega I thought about making it fool-proof by reading the group name via groupname=$(stat -c %G /dev/uinput) and using $groupname instead.

But I'm not sure if the intention is to set uinput ownership to a different group in the first place, which fails on our systems. Adding a user to the input group grants full control over all input devices, which can be a security risk.

I'm not sure if my proposed fix is just a dirty hack that could potentially introduce more problems. Maybe if you reopen this issue someone who is more knowledgeable will add his thoughts.

[quazar-omega]

Good idea, done.

Perhaps it would be good to bring this to the attention of Fedora somehow?
Unless @H-M-H knows something more already