slock Configuration^
As with many tools from Suckless.org, slock derives its
configuration at compile-time from a config.h header file.
If you want to modify the default configuration, you must
update the config.h, recompile, and reinstall slock.
User and Group Privileges^
The user and group constants specify the user and group
that slock should operate as. It defaults to nobody:nogroup,
which is the setting of least privilege.
2static const char *user = "nobody";
3static const char *group = "nogroup";
When slock runs it starts with the privilege of the user that calls it. This can be problematic in cases where it’s called through a display manager since it would mean slock executes as root.
To mitigate the security vulnerability, after slock blanks the screen and claims input, it no longer needs elevated privileges. So, it locks itself down to a user and group with much lower privileges than the caller.
Many, but not all, Linux distributions have nobody:nogroup
set up as the user/group account of least privilege. This makes
it a convenient default for most users. But, in cases where you
are using another UNIX-based operating system, a hardened
system, or a system with strict audit requirements that does not
provide this user/group account, you can update these setting to
have slock drop into whatever pairing suits your particular use
case.
Color Configuration^
When slock runs, it goes through three states.
|
Indicates that the user has initialized slock. |
|---|---|
|
Indicates that slock is receiving input. |
|
Indicates that slock received the wrong password. |
Unlike many login managers, slock doesn’t provide a convenient
dialog box that shows you what you’re doing. Instead it alters
the screen color to indicate what’s happening. The colorname
constant allows you to specify which colors it uses for each
state.
5static const char *colorname[NUMCOLS] = {
6 [INIT] = "black", /* after initialization */
7 [INPUT] = "#005577", /* during input */
8 [FAILED] = "#CC3333", /* wrong password */
9};
By default, slock blacks the screen when initialized. When it receives input it shifts the screen to a shade of blue, then turns red on failed passwords.
If the password is successful, it removes the blank and the input claim, showing whatever was on the screen before it was initialized.
Fail on Clear^
When a user attempts to login through slock, failed attempts are
logged just like any other time when you’re required to provide
a password. The failonclear constant determines whether
slock treats an Esc or Ctrl + u to clear
the password as a failed attempt.
12static const int failonclear = 1;
On many systems this may not be especially important. The failed
login attempt gets logged in /var/log/auth.log, but not much
else happens.
But, it can be very useful from a security perspective if you have the system configured for this purpose. For example, you might configure PAM to lock the account in the event of too many failed login attempts in a row. Including clears in this check may help a stolen laptop get its account locked faster.
If this feature is not desirable, you can disable it by setting
failonclear to 0.