Issues with unpriviledged systemd user setup

[drjaska]

I tried following the instructions in README.md and the example systemd service but I found myself with Can't connect to display ":0": b'Authorization required, but no authorization protocol specified\n' errors.

I have created that user and the group, installed keyszer where that user can launch it, but it doesn't have any authentication ways nor permissions to connect to my own user's display which I start with startx on the TTY without a login manager display manager or systemd. Any help would be appreciated as I'm all out of ideas (other than running keyszer as root...).

My systemd service:

[Unit]
Description=keyszer

[Service]
ExecStart=/home/keymapper/bin/keyszer -c /usr/local/etc/keyszer/config.py
Restart=on-failure
RestartSec=3
Environment=DISPLAY=:0
User=keymapper
Group=input

[Install]
WantedBy=graphical.target

Systemd logs:

Dec 20 23:41:14 kusinenvittu systemd[1]: Started keyszer.service - keyszer.
Dec 20 23:41:47 kusinenvittu keyszer[6861]: keyszer v0.6.92
Dec 20 23:41:47 kusinenvittu keyszer[6861]: (--) Autodetecting all keyboards (--device not specified)
Dec 20 23:41:47 kusinenvittu keyszer[6861]: (+K) Grabbing 'AT Translated Set 2 keyboard' (/dev/input/event0)
Dec 20 23:41:47 kusinenvittu keyszer[6861]: (--) Ready to process input.
Dec 20 23:41:47 kusinenvittu keyszer[6861]: (EE) Can't connect to display ":0": b'Authorization required, but no authorization protocol specified\n'
Dec 20 23:41:47 kusinenvittu keyszer[6861]: (EE) Can't connect to display ":0": b'Authorization required, but no authorization protocol specified\n'
...
Dec 20 23:42:27 kusinenvittu keyszer[6861]: (EE) Can't connect to display ":0": b'Authorization required, but no authorization protocol specified\n'
Dec 20 23:42:27 kusinenvittu systemd[1]: Stopping keyszer.service - keyszer...
Dec 20 23:42:27 kusinenvittu keyszer[6861]: (EE) Can't connect to display ":0": b'Authorization required, but no authorization protocol specified\n'
Dec 20 23:42:27 kusinenvittu keyszer[6861]: (EE) Can't connect to display ":0": b'Authorization required, but no authorization protocol specified\n'
Dec 20 23:42:27 kusinenvittu keyszer[6861]: signal TERM received
Dec 20 23:42:27 kusinenvittu keyszer[6861]: (-K) Ungrabbing 'AT Translated Set 2 keyboard' (removed)
Dec 20 23:42:27 kusinenvittu systemd[1]: keyszer.service: Deactivated successfully.
Dec 20 23:42:27 kusinenvittu systemd[1]: Stopped keyszer.service - keyszer.

[joshgoebel]

Have a look at: https://github.com/joshgoebel/keyszer/blob/485026c773383d3d7d84373e351985c39cc7aa2e/USING_WITH_KINTO.md?plain=1#L52

We probably should update the docs, but pretty sure I recall you also needing to muck about with xhost to allow the unprivleeged user access to the current/active users X session/display.

[joshgoebel]

I'm not saying use that command... since it mentions root... but pretty sure xhost is the key. Please share what you learn and a PR docfix would be welcome.

[drjaska]

https://gitlab.com/drjaska-projects/configs/distro-setup/-/blob/master/install/deb/individual-app/keyszer.sh

I think I have an OK setup now. I set up a systemd system service file which is ran as the user keymapper and the service starts an xvfb virtual headless framebuffer and then attaches keyszer to it.

Had I used xhost then keyszer would have depended on some arbitrary user's X11 server and there is not a good API AFAIK for running anything after some arbitrary user starts an X11 server with ?? display name AND allows keymapper to access it by adding it to the access list with xhost. That setup would have been really hacky or have had hardcoded parts to it. The current setup doesn't even require any logged in users to the system, but at the very tiny cost of running a headless virtual framebuffer purely for keyszer.

[joshgoebel]

there is not a good API AFAIK for running anything after some arbitrary user starts an X11 server

You wouldn't run keyszer after, you'd run it before - and it would just error/wait to connect until access to the X server was granted using xhost (perhaps in startx, etc).

cost of running a headless virtual framebuffer purely for keyszer.

I'm not sure I follow. One of the biggest features of keyszer is knowing which application is active and dynamically changing the keymaps to suite. If you don't care about that functionality (you're just using global remaps) then you wouldn't need the connection to an X server at all... never really considered that as it's a loss of SO much functionality - and probably much simpler tools you could use if you only want a global remap.

[drjaska]

I guess that xhost access list setup works too if you always know what display ID you will have and reserve it for your use, regardless of what seat or display your user gets. Like on a single user system where you always can have :0 or :69. But I can't figure out how to cleanly run this setup so that it's flexible and not hardcoded to have specific IDs or helper scripts.

But personally I don't use any of keyszer's X11 communication capabilities as of now, I just use keyszer because all other keymappers I have looked at have not worked the way I wanted them to or they have had some flaws. I did spend a week trying out others but didn't find anything reasonable to migrate to. I'd even consider it a minus if my keymapper stops working as I kill my X11(Or Wayland in the possible but distant future) and drop to TTY.

[joshgoebel]

regardless of what seat or display your user gets

I guess in that case you'd need a way for the user to communication to the daemon which display was "active"... hasn't really been a problem most people have though...

personally I don't use any of keyszer's X11 communication capabilities

I'd be open to a PR that disabled the X11 stuff entirely if it was clean enough. A placebo X context object could probably be passed instead of a real one - and it would just never match any of the rules - effectively disabling all the X11 specific functionality - like custom keymaps per app, etc.

If you wanted to start that discussion just start another issue along those lines and we could flesh it out a little more.