Permission of /tmp/.ydotool_socket is too restricted

[dashezup]

In order to access /dev/uinput, I added the udev rules to allow users of input group to access to it
KERNEL=="uinput", GROUP="input", MODE="0660", OPTIONS+="static_node=uinput"

And I have a system service to run ydotoold (with setuid root and setgid input), it creates /tmp/.ydotool_socket with permission 600

$ ls -l /tmp/.ydotool_socket
srw------- 1 root input 0 Jul 22 09:28 /tmp/.ydotool_socket

The problem is my user can't read or write to the socket file so it still can't connect to the backend, even though my user is in the input group. seems the permission of the socket file should be at least 660 to allow the user in the group to access it.

One of the solution is let the service run ydotoold with my uid and gid input, so the .ydotool_socket's ower will be my user. But

• It's a bad idea to write username is service file
• Other users in input group still can't connect to the backend
• Can't package a working service file in package

The better solution is creating a folder in /tmp and save socket file inside it, I saw it was mentioned in an answer on stackoverflow.

I'm using ydotool on Void Linux (the init system is runit), but I guess this issue should also present in systemd distros? How do they use ydotoold service? Run it as a user service?

Run it as a user service does not work here with runit, because I need to set the gid to input to ydotoold binary. Although run ydotoold from CLI works.

[ClassicOldSong]

Run ydotool each time with sudo could get this problem resolved. Since ydotool uses a different approach than xdotool, it creats a virtual input device which may apply anywhere including ttys. This could cause some unwanted security issues when allowing .ydotool_socket to be accessed by non-root users.

[dashezup]

It makes ydotool a bit useless if I need to type it with sudo each time (my main use case is use it with pass to automatically type password for me, ideally run it in dmenu).

I don't think it could cause security issues by just allowing the members of the group to read and write to the file, if it's dangerous then such udev rules is also dangerous because it simply let the user of the input group to access /dev/uinput

[wucke13]

I second @dashezup opinion. A reasonable thing would be to make the group owner of the socket the users or the wheel group, depending on how restrictive one wants to be.

[dashezup]

No need to specify owner and group of the socket file in source code, service managers should be able to do that (by setuid and setgid before run it).

I use a custom udev rule to allow users in input group to access /dev/uinput (permission 660)
crw-rw---- 1 root input 10, 223 /dev/uinput

But ydotool always create socket file in 600 permission
srw------- 1 root root 0 /tmp/.ydotool_socket
So, when I run ydotoold with service manager with setuid and setgid, I still can't access the socket file
srw------- 1 root input 0 /tmp/.ydotool_socket

I can do anything with uinput anyway, run ydotoold with my current user and I will be able to access the socket file (since the ower and group will be my user/group).

Specifying group permission is not dangerous, just don't give permission to "other users" (the third permission triad). Permission 660 is fine.

[dashezup]

If you really think 660 could cause security issues, the ideal solution would be check permission of /dev/uinput and set the same permission to the socket file.

[ghost]

@dashezup you can just do ydotoold --socket-perm 0660, though yeah, that should probably be on by default

[ReimuNotMoe]

925b2cc

[ElectricRCAircraftGuy]

I wrote a full tutorial where I show how to start the daemon in such a way that sudo is never needed to run the main tool, by letting the user own the socket file.

The daemon allows setting the permissions and ownership as you start it.

Full details on my personal website here: https://gabrielstaples.com/ydotool-tutorial/#gsc.tab=0

See #207 (comment)