[Solved] Is it discouraged to be part of `input` group ?

phoenix324 · 2025-01-17 13:17:38

My question is in regard to libinput-gesture, where it ask the user to be a part of `input` group which would make every program be able to read /dev/input/*

I found these other refrences -->
https://www.reddit.com/r/linuxquestions … up_secure/
https://askubuntu.com/questions/1057120 … oup-secure
https://bbs.archlinux.org/viewtopic.php?id=191593

But i wanted to know, whats the current status ? Is it bad?

What are the other alternatives?
- Have a native integration for libinput (device management and event handling library) ? i.e Hyprland uses this library and exposes the configs for touchpad gesture.
- ACL, capabilities? ( i don't know just throwing random terms )
- Anythin else ?

Last edited by phoenix324 (2025-01-21 13:19:15)

Lone_Wolf · 2025-01-18 14:26:05

https://wiki.archlinux.org/title/Users_ … emd_groups

phoenix324 · 2025-01-18 16:15:23

@Lone_Wolf, i read the linked wiki.

What are your thoughts on using `linux capability` (sudo setcap cap_sys_rawio=eip /usr/bin/myinputprogram) to only grant the application which needs access to /dev/input/* or should i just add myself to `input` group.

If your suggestion is for `linux capability`, i think we can add this info in libinput-archwiki

Edit: I just read more about `cap_sys_rawio`, and its give access to other io like /dev/mem, /dev/sda.

Edit2: What do you think about flatpak `dev=input`, will it solve the issue ?
- https://alternativeto.net/news/2025/1/f … -and-more/
- https://github.com/flatpak/flatpak/issues/5681

What i am trying to avoid is having any/every program that i run being able to access /dev/input/*. Or am i being too paranoid and its not a big deal ?

Last edited by phoenix324 (2025-01-18 16:24:51)

Lone_Wolf · 2025-01-18 17:08:27

The default now is to use udev rules with uaccess and let logind handle the permission .

If you look at /usr/lib/udev/rules.d/70-uaccess.rules you'll see there's one device from the input system in it :

# joysticks
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess"

With udev rules you can limit access to a specific device, possibly even a specific brand & model .

Adding yourself to the input group feels like using a sledgehammer to insert a pushpin in softboard.

What exactly are you trying to block/limit ?

phoenix324 · 2025-01-18 17:42:50

Fusuma and libinput-gesture provides Multitouch gestures for touchpad using libinput. But they need to have permission for /dev/input to read the touchpad device, which they say can be done by becomming a member of `input` group. But the problem is every other app also gains access to /dev/input this way.

I wanted a way to limit the access to Fusuma and libinput-gesture only.

Also, under wayland is it the job of compositor to provide all those touchpad gesture? If yes, then i can ask in hyprland github in hope they implement them.

Last edited by phoenix324 (2025-01-18 17:43:04)

Lone_Wolf · 2025-01-19 10:40:19

Both softwares look like they were started when input group was still common, and it seems possible that part of the readme file was not updated.

ruby-fusuma and libinput-gestures are in AUR and appear to have active maintainers.

libinput-gestures does require membership of the input group, ruby-fusuma doesn't mention it.

libinput does support gestures, fusuma & libinput-gestures just add additional gestures.

Are you sure you need those extra gestures ?

phoenix324 · 2025-01-19 17:07:44

ruby-fusuma also requires `input` group, https://github.com/iberianpig/fusuma?ta … pad-device

-------------

So my question, under wayland. The only secure way to get more touchpad gesture is if Hyprland, KDE implement them in there environment?

is it possible through flatpak ? flatpak has permission `device=input` and `device=all` https://docs.flatpak.org/en/latest/sand … ice-access

Last edited by phoenix324 (2025-01-19 17:34:23)

Lone_Wolf · 2025-01-20 11:50:45

Both softwares look like they were started when input group was still common, and it seems possible that part of the readme file was not updated.

If ruby-fusuma does still require membership of input group, then the aur package for it is broken as it doesn't convey that information to the user.

Flatpak comes with its own security issues that are worse then being a member of a deprecated local group.

Both KDE & gnome appear to have their own set of additional gestures, so in theory hyprland devs could add some also.

Why are you afraid of using the input group ?

If keyloggers are your concern, those typically don't bother (ab)using the input group.
Infection via Internet Browsers is much easier.

phoenix324 · 2025-01-20 18:19:14

Flatpak comes with its own security issues that are worse then being a member of a deprecated local group.

Can you give some links, would love to read them, as i was moving all my AUR and some arch-packages towards flatpak.

Why are you afraid of using the input group ?
If keyloggers are your concern, those typically don't bother (ab)using the input group.
Infection via Internet Browsers is much easier.

Wanted someone experienced to provide some kind of reassurance or some alternatives.

Lone_Wolf · 2025-01-21 12:48:47

The first colored box on https://wiki.archlinux.org/title/Flatpak should already give an idea .

Personally I feel the biggest security problem of flatpak are the runtime packs that replace system libraries.

How well are they maintained & updated ?
Even if the runtimes are uptodate , will flatpak application maintainers use them or stay with older insecure versions ?

Essentially it comes down to who you trust more : arch linux devs/rolling release or flatpak devs/application maintainers/ flatpak ecosystem (incl. sandboxes)

back to the /dev/input devices :

Device access
You can provide the following device permissions:
....
input
Input devices as exposed in /dev/input. This includes game controllers. Since Flatpak 1.15.6.

So flatpak gives the same rights that being a member of the input group gives.
It just makes it possible to limit those rights to some applications.

Is that enough reason to use flatpaks ?
Only you can answer that.

To answer the original question :
Yes, being part of / using the input group is discouraged.
The uaccess method of udev + logind session management is a lot better.

There are also other alternatives like sandboxing.

phoenix324 · 2025-01-21 13:18:17

Personally I feel the biggest security problem of flatpak are the runtime packs that replace system libraries.
How well are they maintained & updated ?
Even if the runtimes are uptodate , will flatpak application maintainers use them or stay with older insecure versions ?

Yes, it would be good if flatpak could enforce them to use latest runtime, as because they don't depend on system libraries, even if system is debian they could use latest runtime with security update and have feel of rolling release.

The uaccess method of udev + logind session management is a lot better.

I will go with this then, better to only have touchpad readable by my account than all input devices. I found this https://www.reddit.com/r/linuxquestions … up_secure/ and will use archwiki to figure out the rest.

Thank You.

Edit: asked on flatpak matrix and flatpak won't work for this -->

a Flatpak app runs as your user, so at best it can do what your user can do. --device=input merely provides access to the device nodes.

Solution-> udev+tag:uaccess

- https://www.reddit.com/r/archlinux/comm … readwrite/
- https://wiki.archlinux.org/title/Gamepa … ermissions
- https://github.com/ValveSoftware/steam- … nput.rules

Granting access to uinput and touchpad is better that being part of `input` group.

https://www.reddit.com/r/linuxquestions … are_button an example of udev rule for touchpad that i am using.

- Got the attributes by running `sudo evtest` and then selecting events which i though belong to touchpad, performing action on touchpad to see if output shows in evtest. Then using `$ udevadm info --attribute-walk --name=/dev/input/<event-id>` to get attributes.
- Using udev rule from steaminput for `uinput`

Last edited by phoenix324 (2025-01-28 02:21:34)

Arch Linux

#1 2025-01-17 13:17:38

[Solved] Is it discouraged to be part of `input` group ?

#2 2025-01-18 14:26:05

Re: [Solved] Is it discouraged to be part of `input` group ?

#3 2025-01-18 16:15:23

Re: [Solved] Is it discouraged to be part of `input` group ?

#4 2025-01-18 17:08:27

Re: [Solved] Is it discouraged to be part of `input` group ?

#5 2025-01-18 17:42:50

Re: [Solved] Is it discouraged to be part of `input` group ?

#6 2025-01-19 10:40:19

Re: [Solved] Is it discouraged to be part of `input` group ?

#7 2025-01-19 17:07:44

Re: [Solved] Is it discouraged to be part of `input` group ?

#8 2025-01-20 11:50:45

Re: [Solved] Is it discouraged to be part of `input` group ?

#9 2025-01-20 18:19:14

Re: [Solved] Is it discouraged to be part of `input` group ?

#10 2025-01-21 12:48:47

Re: [Solved] Is it discouraged to be part of `input` group ?

#11 2025-01-21 13:18:17

Re: [Solved] Is it discouraged to be part of `input` group ?

Board footer