[arch-general] Why does a regular user have access to /dev/uinput (and why only temporary)
Hello, I'm currently developing a usermode input driver using uinput. While doing this, I've found some "ugly" behaviour. If I do getfacl from my regular user, I get: $ 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 for whatever reason my user is able to launch a usermode input driver. No root permission needed. But in fact the driver isn't even loaded (no uinput module). But it is loaded as soon as I try to access the device. After that, I have: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- #effective:--- group::--- mask::--- other::--- So somehow the permission is still there, but no longer effective??? If I switch VT once (and probably switching the active session this way) I have permission again and now my user keeps it. What is causing this ugly behaviour? Why does a user have to have uinput permissions at all? The (possible security) problem with this is, that the driver (may be a simulated keyboard driver) keeps active even if the session changes. So a software, launched in one session, affects another session. Thanks in advance Manuel
I've been searching a little more and found it: https://bugs.archlinux.org/task/47995 On 02/02/2016 06:41 PM, Manuel Reimer wrote:
Hello,
I'm currently developing a usermode input driver using uinput.
While doing this, I've found some "ugly" behaviour.
If I do getfacl from my regular user, I get:
$ 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 for whatever reason my user is able to launch a usermode input driver. No root permission needed.
But in fact the driver isn't even loaded (no uinput module). But it is loaded as soon as I try to access the device. After that, I have:
$ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- #effective:--- group::--- mask::--- other::---
So somehow the permission is still there, but no longer effective???
If I switch VT once (and probably switching the active session this way) I have permission again and now my user keeps it.
What is causing this ugly behaviour? Why does a user have to have uinput permissions at all? The (possible security) problem with this is, that the driver (may be a simulated keyboard driver) keeps active even if the session changes. So a software, launched in one session, affects another session.
Thanks in advance
Manuel
$ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- #effective:--- group::--- mask::--- other::---
So somehow the permission is still there, but no longer effective???
If I switch VT once (and probably switching the active session this way) I have permission again and now my user keeps it.
What is causing this ugly behaviour? Why does a user have to have uinput permissions at all? The (possible security) problem with this is, that the driver (may be a simulated keyboard driver) keeps active even if the session changes. So a software, launched in one session, affects another session.
device nodes tagged with 'uaccess' by udev are given to the current seat user by logind. see what has TAG+="uaccess" in /usr/lib/udev/rules.d/ -- damjan
participants (2)
-
Damjan Georgievski
-
Manuel Reimer