I've got in the habit of using Ctrl-C with login(1) to restart password entry.
If Sway does the same thing I don't have to retrain my login muscle memory ;)
Today I learned that GNU flaunts the POSIX standard in yet another
creative way. Additionally, this adds some security improvements,
namely:
- Zeroing out password buffers in the privileged child process
- setuid/setgid after reading /etc/shadow
It's better to use DT_RPATH dynamic section of the elf binary to store
the paths of libraries to load instead of overwriting LD_LIBRARY_PATH
for the whole environment, causing surprises. This solution is much more
transparent and perfectly suitable for running contained installations
of wayland/wlroots/sway.
The code unsetting the LD_LIBRARY_PATH/LD_PRELOAD was also deleted as
it's a placebo security at best - we should trust the execution path
that leads us to running sway, and it's way too late to care about those
variables since we already started executing our compositor, thus we
would be compromised anyway.
This involves setuid'ing swaylock, which then forks and drops perms on
the parent process. The child process remains root and listens on a pipe
for requests to validate passwords against /etc/shadow.
The "login" PAM configuration means somathing entirely different on
FreeBSD than on Linux: if you try to authenticate as the calling user,
it OKs the request without prompting for password. The "passwd" config
implements the desired functionality, therefore it should be used by
swaylock.
The whole state->xcb.modifiers thing didn't work at all (always 0)
The xkb doc says "[xkb_state_serialize_mods] should not be used in
regular clients; please use the xkb_state_mod_*_is_active API instead"
so here it is
Milkey Mouse
bschacht
Cameron Nemo
emersion
madblobfish
Drew DeVault
Ryan Dwyer
Ian Fan
Connor E
espkk
Arkadiusz Hiler
Geoff Greer
sghctoma
Brian Ashworth
Dominique Martinet
Bor Grošelj Simić