PermissionError: [Errno 13] Failed to open the uinput device: Permission denied

[damies13]

I am trying to use uinput as a standard user, as for my intended usage this is how most people will want to use it.

• I have installed uinput into a python venv using pip install python-uinput
• I have run chmod a=rw /dev/input as root (comment from issue I got nothing reaction from the example code #3)
• I have run /usr/sbin/modprobe -i uinput as the standard user
• I have confirmed the module is loaded with lsmod | grep uinput, I got: uinput 20480 0

I used the mouse example:

import uinput

with uinput.Device([uinput.REL_X, uinput.REL_Y, uinput.BTN_LEFT, uinput.BTN_RIGHT]) as device:
    for i in range(20):
        device.emit(uinput.REL_X, 5)
        device.emit(uinput.REL_Y, 5)

when running this I get:

Traceback (most recent call last):
  File "/home/dave/Documents/github/robotframework-dbus/tmp/uinput_mouse.py", line 3, in <module>
    with uinput.Device([uinput.REL_X, uinput.REL_Y, uinput.BTN_LEFT, uinput.BTN_RIGHT]) as device:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dave/Documents/github/robotframework-dbus/.venv/lib/python3.11/site-packages/uinput/__init__.py", line 190, in __init__
    self.__uinput_fd = fd or fdopen()
                             ^^^^^^^^
  File "/home/dave/Documents/github/robotframework-dbus/.venv/lib/python3.11/site-packages/uinput/__init__.py", line 88, in fdopen
    return _libsuinput.suinput_open()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dave/Documents/github/robotframework-dbus/.venv/lib/python3.11/site-packages/uinput/__init__.py", line 74, in _open_error_handler
    raise OSError(code, msg)
PermissionError: [Errno 13] Failed to open the uinput device: Permission denied

I tried to check dmesg (also based on comment from Issue #3) but current user is not able to access dmesg (dmesg: read kernel buffer failed: Operation not permitted), I when I checked dmesg as root it on;y shows messages from when I tried to run the same example as root, which also did not move the mouse on the desktop of the current logged in user (not surprising I guess)

I'm not sure how to proceed from here? Any advice? does uinput-python work for non-privileged users?

edit:

• Debian 12 (bookworm) 64bit
• Gnome 43.9
• Wayland (This is why I'm looking into uinput-python, pyautogui doesn't work with Wayland)

Dave.

[Imred-Gemu]

There is a small typo in that comment, the uinput device file is usually /dev/uinput, not /dev/input: chmod a=rw /dev/uinput.

Also, this is fine for testing, but you should set this file's permission using a udev rule once you get the basics working such as the file available in this repository should if you installed it into /usr/lib/udev/rules.d/. This file assumes there is a group named uinput available on your system; your package should either ensure that or you should use a group that is available by default on most distros. The user who will be running your program must then be in this group. For security reasons uinput should not be available to all users, only those given permission to access it by being added to some group.

[damies13]

I've tried running chmod a=rw /dev/uinput and also tried adding the udev rule you suggested after creating the uinput groups and adding myself to the uinput groups (logged off and bak on and confirmed with the groups command that it had applied.

Either way, with chmod a=rw /dev/uinputor with the udev rule, I still get the same error.

[Imred-Gemu]

What do the permissions on that file look like? ls -l /dev/uinput should show something like crw-rw---- 1 root uinput 10, 223 Aug 18 11:35 /dev/uinput or crw-rw-rw- 1 root root 10, 223 Aug 18 11:35 /dev/uinput for the udev rule or chmod command respectively. The chmod option should work immediately if the permissions are actually being set. The udev rule however applies when the module loads. You should be able to reapply new rules with udevadm control --reload-rules && udevadm trigger being run as root, or just restart the computer.

I want to note that I haven't tested either of these solutions and I assumed they would work as others had described. If I was doing this myself for the chmod command I would actually run chmod +rw /dev/uinput, which worked for me before, but as far as I know should just do the same thing in this particular use case as the other command.

Likewise the udev rule I actually deploy with my package for adding a uinput group, which my packages that use uinput then depend on, adds a slightly different rule:
cat /usr/lib/udev/rules.d/50-uinput.rules
KERNEL=="uinput", MODE="0660", GROUP="uinput", OPTIONS+="static_node=uinput"
This works on my system, but it's a different distro so I'm not sure it would work for you.

[damies13]

Ah, interesting, so it looks like it might be a permissions issue then:

[damies13]

So i ran as root:

# chown root:uinput /dev/uinput
# chmod 660 /dev/uinput
# ls -l /dev/uinput 
crw-rw---- 1 root uinput 10, 223 Aug 21 23:44 /dev/uinput
#

So not the permissions are the same as yours, and now I get a different error:

$ python tmp/uinput_mouse.py 
Traceback (most recent call last):
  File "/home/dave/Documents/github/robotframework-dbus/tmp/uinput_mouse.py", line 3, in <module>
    with uinput.Device([uinput.REL_X, uinput.REL_Y, uinput.BTN_LEFT, uinput.BTN_RIGHT]) as device:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dave/Documents/github/robotframework-dbus/.venv/lib/python3.11/site-packages/uinput/__init__.py", line 190, in __init__
    self.__uinput_fd = fd or fdopen()
                             ^^^^^^^^
  File "/home/dave/Documents/github/robotframework-dbus/.venv/lib/python3.11/site-packages/uinput/__init__.py", line 88, in fdopen
    return _libsuinput.suinput_open()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dave/Documents/github/robotframework-dbus/.venv/lib/python3.11/site-packages/uinput/__init__.py", line 74, in _open_error_handler
    raise OSError(code, msg)
OSError: [Errno 19] Failed to open the uinput device: No such device

Seems this is progress? no longer a permissions error but something else? Not sure why it says No such device?

Also get that same error message when running that python as root.

[Sgale952]

@damies13 udev rule might not have taken effect because the uinput group is not a system group (typically one with GID < 1000)

[jfly]

I ran into the same issue as @damies13 (OSError: [Errno 19] Failed to open the uinput device: No such device). I traced this error:

1. python-uinput::fdopen calls _libsuinput.suinput_open().
2. suinput_open calls suinput_get_uinput_path.
3. suinput_get_uinput_path looks for /sys/devices/virtual/misc/uinput, which did not exist on my machine.

This was not a permissions issue with /dev/uinput, it was because I was missing the /sys/devices/virtual/misc/uinput folder. This folder exists (gets created?) once the the uinput kernel module is loaded. On many systems, I think it implicitly gets loaded because some piece of software tries to read /dev/uinput, which... somehow causes the uinput module to get created.

Proof of this. Note how I have a /dev/uinput, but no uinput kernel module, nor a /sys/... entry:

# ls -alh /dev/uinput
crw------- 1 root root 10, 223 Nov 23 11:29 /dev/uinput

# ls -alh /sys/devices/virtual/misc/uinput
ls: cannot access '/sys/devices/virtual/misc/uinput': No such file or directory

# lsmod | grep -i uinput

And now, if I try to read /dev/uinput, the uinput kernel module gets loaded:

# cat /dev/uinput
cat: /dev/uinput: No such device

# ls -alh /sys/devices/virtual/misc/uinput
total 0
drwxr-xr-x  3 root root    0 Nov 23 11:32 .
drwxr-xr-x 20 root root    0 Nov 23 11:29 ..
-r--r--r--  1 root root 4.0K Nov 23 11:32 dev
drwxr-xr-x  2 root root    0 Nov 23 11:32 power
lrwxrwxrwx  1 root root    0 Nov 23 11:32 subsystem -> ../../../../class/misc
-rw-r--r--  1 root root 4.0K Nov 23 11:32 uevent

# lsmod | grep -i uinput
uinput                 20480  0

A less convoluted way of doing this is to explicitly load the module with: modprobe uinput.

What I don't know is if this a bug, and if it is, who is responsible for fixing it: should python-uinput explicitly load the uinput module? Should libsuinput? Is this ultimately the responsibility of the sysadmin?

Regardless of whose fault it is, it's definitely too difficult to debug. It would probably be nice if libsuinput printing out some warnings about what's going on.