readme.md improvements for running keyszer on semi-privileged users

[drjaska]

readme.md could be improved so that new users adopting keyszer don't have to figure out anything. This makes it easier to adopt new software as the installing process is easy and the end product is safer than running it as the active user or as root.

Currently:

• users created after installing the recommended way don't have a keyszer to run
• there is no mentions of having keyszer run with that isolated user on system boot or when logging into the active user
• above could be fixed by Lack of an example systemd keyszer.service despite its mention in readme #67 potentially?
• udev rule addition could be copypasteable with

cat <<EOF | sudo tee /etc/udev/rules.d/90-keymapper-acl.rules
KERNEL=="event*", SUBSYSTEM=="input", RUN+="/usr/bin/setfacl -m user:keymapper:rw /dev/input/%k"
KERNEL=="uinput", SUBSYSTEM=="misc", RUN+="/usr/bin/setfacl -m user:keymapper:rw /dev/uinput"
EOF

• privileged is typo'd in running-as-a-semi-privleged-user title

If logging into the new user is necessary them mentioning su - keymapper or another way to login on the newly created user should be mentioned as the user created with sudo useradd keymapper does not have a password and logging into them with su keymapper isn't possible creating a small issue for inexperienced Linux users to search for themselves instead of it being seamless.

[drjaska]

This isn't a bug but I'm unable to manage the labels myself.

[joshgoebel]

Can this be closed by #69 then?

[drjaska]

#69 in its current state doesn't solve all of the listed issues and new users of keyszer don't have a copypasteable installation tutorial in the readme which would allow them to run keyszer on a semi-privileged user for the most secure setup configuration.

I've yet to check if only writing installation commands and comments for files from #71 would work flawlessly.