move config.h inclusion after type declarations
Use explicit strcmp() instead of inlining it
Makes it a tad more readable; the previous "optimization" will be done
by the compiler anyway.
No need for oldc to be static
Use NUL character constant explicitly
Keep the line-lengths at bay
This makes the code more readable and prevents wraparounds in the
editor.
remove confusing DPMS comment
FRIGN on hackers@suckless.org:
What has been bugging me for quite a while is this DPMS comment that was added
there for no reason. Every sane mind would agree that fiddling with DPMS makes
no sense whatsoever. When I slock, my screen turns off after 10 minutes. So, if
I don't like that, I disable DPMS. If I do, I just fiddle around with my mouse a
bit and get the slock promt.
error out early on crypt() fail
Stop using $USER for shadow entries
This was extremely bad practice, effectively making the program behave
different depending on which architecture you are running it on.
OpenBSD offers getpwuid_shadow, but there is no getspuid for getspnam,
so we resort to using the pw_name entry in the struct passwd we filled
earlier.
This prevents slock from crashing when $USER is empty (easy to do). If
you want to run slock as a different user, don't use
$ USER="tom" slock
but doas or sudo which were designed for this purpose.
Rename getpw() and pws to gethash() and hash
Remove cleanup and deglobalize and rework data structures
The cleanup removal is a joint-venture with Markus. We assume the X server does
the cleanup, so we don't need it. The idea is that the fds are closed at exit
and thus already indicate to the X server that the client has quit. Analogously
the same applies to freeing memory sections previously allocated for the X
server.
We love XXXXXL burgers and therefore removed
XUngrabPointer
XUngrabKeyboard
XFreeColors
XFreePixmap
XDestroyWindow
Lines of Code.
For a project like slock there is no need to carry around global state. By
moving the three structures to main() it is now clear which functions modify
which state, greatly improving the readability of the code, especially given
slock is a suid program.
Ensure Polyphemus-Mitigation and properly drop privileges
Don't hide privilege drops inside readpw() and actually make it
configurable what you are dropping to in config.h.
The privilege drop comes after opening the Display because the
user "nobody" with "nogroup" can't do that.
So why do I call this strategy the Polyphemus-Mitigation?
"""
After the giant returns in the evening and eats two more of the men,
Odysseus offers Polyphemus some strong and undiluted wine given to him
earlier on his journey. Drunk and unwary, the giant asks Odysseus his
name, promising him a guest-gift if he answers. Odysseus tells him
"Οὖτις", which means "nobody" and Polyphemus promises to eat this
"Nobody" last of all. With that, he falls into a drunken sleep. Odysseus
had meanwhile hardened a wooden stake in the fire and now drives it into
Polyphemus' eye. When Polyphemus shouts for help from his fellow giants,
saying that "Nobody" has hurt him, they think Polyphemus is being
afflicted by divine power and recommend prayer as the answer.
"""
(source: https://en.wikipedia.org/wiki/Polyphemus)
Unify how we check passwords between different OSes
make error message prefix consistent
increasing for loops are idiomatic
Localize running and failure inside readpw()
They are only needed there, so don't make them global.
Move screen unlocking inside cleanup()
Re-introduce the waiting loop for input grabbing
We actually “need” to wait a little for input to be released before
locking for cases where slock is spawned from other graphical
applications using keybindings.
This undoes the misbehaviour I introduced in c2f9757, sorry for the mess.
Add cleanup() to do free(locks) + XCloseDisplay()
Refactor dontkillme()
- Use file pointers instead of raw I/O, inspired by Kernel code.
- Use OOM_SCORE_ADJ_MIN from linux/oom.h instead of working with
magic values.
- Stricter error checking and descriptive error messages.
The reasoning for using the constant rather than magic values lies
in the fact that this ensures people get the message.
With "-1000", a code reviewer would question if that is really the
lowest possible number or just an arbitrary value.
The kernel ABI probably won't change, but even in the case, we wouldn't
have to modify the code. The OOM killer only is guaranteed to not
kill you if you have OOM_SCORE_ADJ_MIN.