Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove device instead of 000 permissions? #5

Closed
hhromic opened this issue Oct 28, 2015 · 6 comments
Closed

Remove device instead of 000 permissions? #5

hhromic opened this issue Oct 28, 2015 · 6 comments

Comments

@hhromic
Copy link

hhromic commented Oct 28, 2015

Hi !
first, thanks A LOT for this repository!. I had this issue with my Microsoft Wireless keyboard on my Raspberry Pi running OSMC (the trackpad being recognised as a joystick, hence my emulators were going crazy) and had no idea what was going on. Your rules totally solved my problem. However I found two small issues with your solution that I would like to bring for discussion and hopefully integrate into your solution:

  1. [small] The rules file name 999-these-are-not-joysticks.rules should be the very last to execute to make sure other rules don't re-create or interfere with the joystick devices. In the case of OSMC, unfortunately this naming didn't put it at the end so I had to make the number even bigger: 9999-these-are-not-joysticks.rules. No big deal, but maybe we can name the file even bigger to make absolutely sure it will be the last one in almost everyone's computer.
  2. The idea of changing permissions to 0000 is nice and it worked for me. However, programs can still see the devices and try to open it. No big deal except that most of the times they throw access denied warnings. In my case is just annoying but I got thinking that maybe some other programs may crash instead of just warning the user. For this reason I explored the idea of deleting the joystick device files and so far it's been working very nicely in my setup. So I propose to use the following rules instead of the ones you provided:
SUBSYSTEM=="input", ATTRS{idVendor}=="%s", ATTRS{idProduct}=="%s", ENV{ID_INPUT_JOYSTICK}=="?*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""
SUBSYSTEM=="input", ATTRS{idVendor}=="%s", ATTRS{idProduct}=="%s", KERNEL=="js[0-9]*", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""

As you can see, what I do is to simply delete the device file for those detected as joysticks. I can create a pull request to help merge this if you think is a good idea. Personally I think this is cleaner because programs never ever see those devices instead of trying to open and failing.

What do you think?
Hugo.

@denilsonsa
Copy link
Owner

Regarding the file name, I chose 51-*.rules on purpose, because there are other later rules that check if ID_INPUT_JOYSTICK is set. Look:

$ grep JOYSTICK /lib/udev/rules.d/*
/lib/udev/rules.d/60-persistent-input.rules:ENV{ID_INPUT_JOYSTICK}=="?*", ENV{.INPUT_CLASS}="joystick"
/lib/udev/rules.d/70-uaccess.rules:SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess"
/lib/udev/rules.d/70-udev-acl.rules:SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="udev-acl"

Undoing those rules later on is more difficult, specially the udev-acl and uaccess ones. I'm using a Lubuntu 15.04 system.

I don't have access to any Raspberry Pi system, I can't check it.


Regarding removing the device, I always feel over-cautious regarding running rm, specially in automated script that run as root.

Still, I see why some users may want to do that. I think I'll generate a second file that deletes the device instead of removing the permissions. Then, the user can choose which file will be installed.

Also, as a bonus, removing the device will most likely "fix" the issue of filename order (51-* or 9999-*).

@denilsonsa
Copy link
Owner

@hhromic I've just pushed the alternate version. Any comments?

@hhromic
Copy link
Author

hhromic commented Oct 28, 2015

Hi Denilson,

Ah you are right! When the rules remove devices, the order doesn't matter anymore so 51-* works for me now. I didn't think of that, good catch.

Regarding the two versions, I agree. It makes sense for the end-user to decide if he/she wants to remove the device files or to remove permissions instead.

Good work with this repo, and hope the Kernel is fixed soon. I hate patches. By the way, I will try to make the OSMC guys to bring this patch into the official distribution. Thanks again!

Hugo.

@denilsonsa
Copy link
Owner

@hhromic Do you know how different are udev rules in your Raspberry Pi, when compared to Ubuntu? Have you tried grepping those rules, looking for JOYSTICK? I'm curious to know why you had to put these rules at the very end.

@hhromic
Copy link
Author

hhromic commented Oct 28, 2015

@denilsonsa I'm using a very particular OS for my Raspberry Pi: OSMC. This is a media-center oriented distribution (very very good by the way). It's fully based on Debian 8 (Jessie). When grepping for JOYSTICK this is what I get:

$ grep JOYSTICK /lib/udev/rules.d/*
/lib/udev/rules.d/60-persistent-input.rules:ENV{ID_INPUT_JOYSTICK}=="?*", ENV{.INPUT_CLASS}="joystick"
/lib/udev/rules.d/70-uaccess.rules:SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess"

However, OSMC in particular brings the following rules in the /etc/udev/rules.d/998-fix-input.rules file:

# input
KERNEL=="mouse*|mice|event*",   MODE="0660", GROUP="osmc"
KERNEL=="ts[0-9]*|uinput",      MODE="0660", GROUP="osmc"
KERNEL=="js[0-9]*",             MODE="0660", GROUP="osmc"

# tty
SUBSYSTEM=="tty", KERNEL=="tty[0-9]*", GROUP="tty", MODE="0666"

What they do is to give ownership of the devices to the user osmc (the main user of the media-center) and give 0660 permissions. This is why I had to move down the rules because these rules rendered the 0000 permissions back to 0660. Now that I'm completely removing the device files, those rules doesn't matter for the purpose of disabling the joystick devices. This is why I consider deletion of the files a more clean/elegant solution/patch.

Let me know if you are curious about any other thing about the Raspberry Pi!

Cheers,
Hugo.

@denilsonsa
Copy link
Owner

I've added a short description of this issue to the README (9cdf6d8). Together with 7460da7, we can close this.

Thanks for bringing it up and for the detailed comments!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants