Describe installation as root; systemd service?

[spikespaz]

Hello!

I want to replace Touchegg because it's buggy and I like Rust.

Goal: run Wzmach as root, allowing it to be used as a systemd service.

I have a few questions:

1. sudo chown "$USER:input" wzmach
   • Should this be root:input or is root:root fine?
2. sudo chmod g+s wzmach
   • Is g necessary if the user is root?
   • What is setuid?
   • Would you mind explaining what this is doing, and what the numerical form of the file permissions should be? I believe it is 2754. The letter flags have always confused me.
3. Where is wzmach going to read the configuration file from if it is run by the user root? Can I have a default config, and then a config per-user?

I'm having a hard time making these decisions myself. I see how services are usually set up, but I've never seen some of this prerequisite setup, and touchegg doesn't use the input group.

I've recently moved from Windows, and I'm still learning the intricacies of Linux. Thanks!

[maurges]

Hello, thanks for your interest. Having an option to install as a systemd service is a nice idea, I'll add it soon!

Here's an explaination about permissions.
In order to receive input events from libinput, the user either needs to be a root, or a member of the "input" group. For example, touchegg uses the root approach and runs a separate daemon that collects the events and sends them over unix-sockets. In wzmach I decided to go with the second approach.
But making a user a member of the "input" group is sort-of unsafe, as then untrusted programs that you run, like discord, can also collect all input events. So one can go with another linux mechanism: setgid. Instead of assigning the "input" group to your user, you can assign the group to the executable itself, and set the sticky group bit. This way, when you run this exact executable, it's as if you are in the "input" group, and the executable can observe all input events without trouble.

So, as for the root permissions. There are a two of ways I see you can organize this:

1. root:root 0744 - non-root can't even run the executable, but root can and will be able to see input events
2. root:input 2755 - anyone can run the executable and see the input events

As for the location of configuration files: even for root it's as the readme says. You can see the location via

> su root -c 'ls ~/.config/wzmach/config.ron'
ls: cannot access '/root/.config/wzmach/config.ron': No such file or directory

[maurges]

Also instead of using a systemd service, I recommend you use your DE's autostart. For most environments it's as simple as putting

[Desktop Entry]
Exec=wzmach
Icon=
Name=wzmach
Path=
Terminal=False
Type=Application

into ~/.config/autostart/wzmach.desktop

[spikespaz]

Thank you for the verbose description of how the permissions work!

A few comments:

I was particularly interested in using it as a systemd service so that Wzmach can be installed from the AUR and other package repositories, most only provide install scripts or definitions for root installs. I have a hidden agenda: I want to maintain the AUR package(s) and bring you some more stars; visibility encourages software stability.

Is there a specific reason you recommend using the distribution's autostart feature, other than the fact that it's popular (read: more correct) to run things as unprivileged users now?

touchegg uses the root approach and runs a separate daemon that collects the events and sends them over unix-sockets

Is this why touchegg often seems to have a bad issue with latency? I find it to be weirdly unreliable, and I wonder if the added complexity with having a dispatcher service and a message handler causes undefined behavior. For example, one longstanding issue with it is that it seems to behave differently after waking up from sleep. It doesn't stop working (anymore, I did report that issue to Jose and he fixed it), but it seems like the gestures are super insensitive. I have to me more "emphatic" with my fingers, if that makes any sense.

I think that may be an issue with libinput though, because I notice that two-finger scrolling is buttery smooth after a fresh boot, but after going into hibernate, I have to touch both fingers down at exactly the same time or it doesn't register as a two-finger swipe. I'm partly asking because I'm considering a form of IPC for my own project but it seems like keeping a reliable connection alive can be a real challenge.

As for the location of configuration files: even for root it's as the readme says.

Wzmach reads configuration from $XDG_CONFIG_HOME/wzmach/config.ron

I wasn't sure if the XDG Base Directories Specification applied to /root. Good to know that it does.

I'm going to make a draft PR for handling behavior specific to user configs, when the Wzmach is running as root. I have a feeling that this is going to be a fun, complicated little task that should help me be a little more familiar with writing platform-(Linux)-specific Rust.

---

I thought of closing with this comment, but maybe you want to keep it open as a tracking issue for your "option to install as a systemd service". My original question has been effectively answered, thank you.

[spikespaz]

Also, is there a reason that you don't have the new GitHub Discussions feature enabled for this repository? I find it quite handy, a nice little forum that can also track progress for the repo. It's good for threads like this, just in case you're unfamiliar.

[maurges]

Haha, I would love it if your would create a package for repositories! I just don't know how building the distributable packages like deb and rpm works, I had scheduled a figuring it out session for next weekend.

I don't advise against global install, I just think that user-local installs are sufficient in most cases. We as a linux community are kind of too fixed on global installations, and I try to lead by example in the opposite direction.

Regarding touchegg's latency: I don't think it's caused by RPC. Unix sockets on linux are very fast. Some milliseconds of latency might be caused by how touchegg re-parses config values for each libinput event, but it's shouldn't be that noticable.

All the latency stuff is caused by libinput and hardware drivers. On my own notebook (lenovo extreme x1 gen 2) after sleep all touchpad interactions becomes sluggish after waking up: cursor movements, scrolling, but it's not so noticable for gestures since they don't have animations. Also it's less noticable on wayland for some reason.

Re: github discussions. I've never used them personally, but I can create them, won't hurt. I plan on leaving github in favour of self-hosted solution, since after some recent events I don't trust big corporations even more. Right now this repo is already a mirror, it's just that the original still doesn't have a website.

And yes, I will keep the issue open to track the addition of a systemd unit and a global install script.

[spikespaz]

I noticed that this TODO comment has gone in 1.1.0, but no new locations are searched: https://github.com/d86leader/wzmach/blob/3352dc8db5991c1644528570fc651dfe83be6d77/src/main.rs#L87

[maurges]

Oh yeah, I decided not to search them. =) Initially I though about cascading configs, like how you first load a "config.ron" and then "x11.ron" or "wayland.ron", and then something from the command line, but that did more harm than good: the combinig logic was weird and the error messages became worse. So i moved x11 and wayland sections to the main config.

I also thought about how someone would want to run this as a global service, and they would expect a config to go into "/etc/wzmach/config.ron" or something. I don't know, it looks more reasonable than the stupid /root/.config/.... But on the other hand, it makes little sense to make this config system-wide and with root permissions: this is a personal configuration that you will want to change a lot, and you would want to do this without the hassle of sudo.

Maybe the middle ground is for the systemd service to be tied to the user session and run as user? Something like those "wildcard" services: systemctl enable wzmach@my_user_name

Also a service running as root is harder to restart after a config change. I did want it to auto-reload the config on changes, but with rust it's a lot harder to do than in haskell, and I wanted to finish the 1.0 as soon as possible.

[maurges]

So anyway, I think that installing in a global location is ok, but running as a global service with global config is not the best way, that DE-local autoloads would work better.

[spikespaz]

I misunderstood what the comment meant. I assumed that everything was staying in one config, sorta thought you intended something like described below.

I was trying to think of a way to handle searching configs in the following order:

Environment variables not used for readability reasons.

$XDG_CONFIG_HOME =? /home/$USER/.config
$USER =? jacob

When running as a user:

Path	Justification
/home/jacob/.config/wzmach.ron	Preference B
/home/jacob/.config/wzmach/config.ron	Preference A
/etc/wzmach/config.ron	Default

When running as root:

Path	Justification
/home/<CURRENT_ACTIVE_USER>/.config/wzmach.ron	User, Preference B
/home/<CURRENT_ACTIVE_USER>/.config/wzmach/config.ron	User, Preference A
/root/.config/wzmach.ron	Preference B
/root/wzmach/config.ron	Preference A
/etc/wzmach/config.ron	Default

I'm not sure how to determine <CURRENT_ACTIVE_USER>. Because a Linux system can have multiple logged-in users, Wzmach would have to pay attention to the current active TTY that the user's display server is using. Can we discern what instance of the display server the input events are coming from? Or rather, how would you suggest associating the events froma certain device with a specific TTY?

[maurges]

So this thread has grown kind of big and focused on too many things. Let me address them and close this thread.

1. I don't want to add more config locations, but I did add /etc in the upcoming release, it was a good idea.
2. I did add support for the global installation, but each user must opt-into the autostart themselves. In case the administrator wants all users to have wzmach, they might add the desktop file into /etc/xdg/autostart.
3. The makefile now has the improved install script, with support for both local install and global install. One might use this in packages for a distribution.
4. Now, I myself don't want to make the packages for the distros. I tried making them for ubuntu and fedora, and it was a huge pain in the ass with not much gain. The installation is really easy even without it, so random people from the internet can do it themselves. But if someone creates those packages for me, I would be really greatful to them! In fact, I shall now create a tracking issue for it.

[spikespaz]

That tracking issue is #10