You are not logged in.

#1 2014-04-01 20:08:48

mastorak
Member
Registered: 2014-04-01
Posts: 27

Input udev rules

Hi,
I had the following problem:
After sometime I realized that mumble was not working properly. The push-to-talk key was not working even though it had been working in the past. Then, I noticed that generally mumble diregarded all input from keyboard.
I figured that something had messed up with the permissions for input. I checked for anything I had installed lately that added stuff to the udev rules but after removing some stuff it still was not working.
The temporary solution was to  add a new udev rule with high priotity, after adding myself to a new group ' input'

KERNEL=="event*",       NAME="input/%k", MODE="660", GROUP="input"
KERNEL=="js*",          NAME="input/%k", MODE="664", GROUP="input"

This fixes my problem but I am wondering if this is the right solution. Could this cause any problems or be a security risk?
I imagine that the best solution would be to find the offending rule added by which ever update/package that messes with the input, but I cannot seem to find it.
Any opinions/suggestions?

Last edited by mastorak (2014-04-03 11:13:56)

Offline

#2 2014-04-03 05:46:00

Rexilion
Member
Registered: 2013-12-23
Posts: 784

Re: Input udev rules

Any use whom belongs to the input group has automatically gained keyboard sniffing capabilities.

Did you upgrade mumble? Does it provide udev rules?


fs/super.c : "Self-destruct in 5 seconds.  Have a nice day...\n",

Offline

#3 2014-04-03 07:20:48

mastorak
Member
Registered: 2014-04-01
Posts: 27

Re: Input udev rules

Thanks for your reply. I suspected something like this would be the downside of this temporary solution.
In this case though, every program running under the user that belongs to the group input  has the keyboard sniffing capabilities in theory, which is even worse. Am I correct to think that?
Yes, mumble is upgraded to the latest version. It does not provide any udev rules.
I am thinking that something else is highjacking the keyboard input by adding a rule.

Last edited by mastorak (2014-04-03 07:29:32)

Offline

#4 2014-04-03 08:17:37

Rexilion
Member
Registered: 2013-12-23
Posts: 784

Re: Input udev rules

Yes, every use that is part of the input group has sniffing capabilities. That implies all of the executables it runs (how else would one sniff?).

Maybe it's just a wm issue. 'Normal' programs should not directly open /dev/input/* nodes. X does that.


fs/super.c : "Self-destruct in 5 seconds.  Have a nice day...\n",

Offline

#5 2014-04-03 09:42:04

mastorak
Member
Registered: 2014-04-01
Posts: 27

Re: Input udev rules

I see. Thank you for the clarification.
I should then remove this "solution" and find out which one is the offending package/rule.

Offline

#6 2014-04-03 10:01:58

Rexilion
Member
Registered: 2013-12-23
Posts: 784

Re: Input udev rules

You are giving a solution. But it's not a decent one.

I googled around, and indeed to my huge surprise, it tries to open /dev/input files directly (which is insane). BUT, it uses an alternative as a fallback (XInput).

Another bad solution (albeit a better one) would be to give mumble sgid priviliges and attach that gid to the /dev/input nodes.

One would have to find a bug inside mumble to tap someone else his/her input data. I cannot think of anything better.

It would *really* help if you could pinpoint when it stopped working. Check /var/log/pacman.log for this.


fs/super.c : "Self-destruct in 5 seconds.  Have a nice day...\n",

Offline

#7 2014-04-03 10:29:57

mastorak
Member
Registered: 2014-04-01
Posts: 27

Re: Input udev rules

Thank you for the time you put into this and the suggestions.
It is more important to have a secure system than a system where mumble(or any app for that matter) works properly so I will try to figure out what was changed and mumble stopped working.

Offline

#8 2014-04-03 10:45:33

Rexilion
Member
Registered: 2013-12-23
Posts: 784

Re: Input udev rules

Yes, good thinking. But the sgid suggestion is far better than what you have right now and it might be wise to consider to apply it right now.

EDIT: Take the [SOLVED] out of the topic's subject. Who knows someone else might kick in to help you out.

Last edited by Rexilion (2014-04-03 10:46:07)


fs/super.c : "Self-destruct in 5 seconds.  Have a nice day...\n",

Offline

#9 2014-04-03 11:13:44

mastorak
Member
Registered: 2014-04-01
Posts: 27

Re: Input udev rules

Yes, as step 1 I will go ahead with the sgid solution just to be more secure and as step 2 I will try to find a more permanent solution.

Offline

Board footer

Powered by FluxBB