> /etc/apm/resume, xlock to lock the screen on resume
I'm not an expert, but people say that if you lock upon resume,
there may be a time span where the system is running and unlocked,
and that is a security hole.
One should lock the environment before putting it to sleep.
There are
/etc/apm/hibernate
/etc/apm/standby
/etc/apm/suspend
files you can try for that,
or perhaps don't rely on automation, where `zzz`-triggers-locking,
and flip direction to locking-triggers-`zzz` to be sure.
I have been using this script:
#! /usr/bin/env es
if { /usr/local/bin/i3lock --show-failed-attempts }{
/usr/bin/doas /sbin/umount /mnt/* /vol/*
/usr/sbin/zzz }
`es` is https://wryun.github.io/es-shell/, not ancient `pkg_add es`.
`sh` would also do, but I personally despise Bourne-family syntax.
https://skarnet.org/software/execline/ is an even better launcher,
I haven't transitioned yet, but let me try this one:
#! /usr/bin/env execlineb
if { /usr/local/bin/i3lock --show-failed-attempts }
foreground /usr/bin/doas /sbin/umount /mnt/* /vol/*
"" /usr/sbin/zzz
`pkg_add i3lock` - `i3lock` forks, so you can use it in `if`.
`umount` is needed coz otherwise certain stuff hangs/freezes IIRC,
of course if it was mounted in the 1st place.
`/etc/doas.conf` must be configured for `umount`.
`zzz` may be more convenient than `ZZZ` or `shutdown -hp now`
but RAM is kept powered and unlocked which is a security hole.
I happened to visit an abandoned special service building once.
Politically challenged region, they had to take flight.
They left their computers and peripheral devices, but
they took all storage - and all RAM sticks - with them.
So even powered down RAM may be considered a security hole.
You may also look at `pkg_add login_duress`.
Even if your use case is not duress per se, but a theft,
you could configure typical passwords like "12345678" or "password"
to `dd` (disk destroy) your first say megabyte of storage where
FDE headers are to turn disk non-decryptable,
and then trigger a `shutdown -hp now`.
Stay safe
