Integrating slock

hendry · 2017-03-02 02:04:16

Hi, I endeavour to live the suckless lifestyle, so I am using http://tools.suckless.org/slock/ with ... umm.. the not so suckless systemd via /etc/systemd/system/slock.service.

My first question here is whether I should be using WantedBy={sleep,hibernate,suspend} ... not entirely sure what the practical difference is here.

Next is a bit crazy: I like to close the lid on my laptop whilst wired to power and for it NOT to suspend / go to sleep. [1] However I do want the screen to lock when I close the lid. How do I integrate slock with that lid closing event? I am not entirely sure how to do that. I think the wiki https://wiki.archlinux.org/index.php/Power_management suggests aclidswitch, but isn't there a simpler way? I hoped it would be as simple as `ExecStart=/usr/bin/systemd-inhibit --what=handle-lid-switch /usr/local/bin/slock` but that _does not work_ since it keeps locking the screen.

Sidenote: I raised this issue on #systemd and they seemed to think I need a graphical login manager which didn't sound suckless to me. Currently I launch Xorg like so: https://github.com/kaihendry/dotfiles/b … sh_profile

[1] ~/.config/systemd/user/inhibit-lid-sleep-on-battery.service

Docbroke · 2017-03-02 06:52:57

1. WantedBy=? depends on after which event you want to lock your screen. Sleep is probable appropriate for most use cases.
2. To lock after lid lock, power-managers (from DEs) or acpid are needed. Though they may go again suckless philosophy. In such case you may look at xss-lock (aur) which basically registers slock as xscreensaver, so when you select "HandleLidSwitch=lock" in logind.conf, it will lock the screen. However my experience with xss-lock has not been good. (It was overheating cpu, after multiple lid close events, and even failed to lock the lid occasionally)
For more weird requirements like suspend when not connected to power, and only lock when connected to power, you may need to right your own script, bypassing the systemd. Just put "HandleLidSwitch=ignore" and run your own script. I am running one such crude script posted here https://bbs.archlinux.org/viewtopic.php … 0#p1694450 , you can add your own conditions.

Docbroke · 2017-03-06 16:30:02

Try this in your startup, (use HandleLidSwitch=ignore in logind.conf)

#!/bin/bash

xlock() {
    ( slock && xset dpms 0 0 60 ) &
    xset dpms 0 0 2
    xset dpms force off
}

while true;
do 
    if [[ $(< /proc/acpi/button/lid/LID0/state) = *closed ]] 
    then
	case $(< /sys/class/power_supply/AC/online) in
	    1)  ( [[ ! "$(pidof slock)" ]] && xlock ) ;;
	    0)	systemctl suspend ;;
	esac
    fi
    sleep 2;
done

seth · 2017-03-06 16:54:08

You could try inotify-watch instead of sleep? (inotify-tools package)

Docbroke · 2017-03-06 17:43:21

I think you mean inotifywait command.
I am able to catch changes (access/open etc.,) in regular files but it fails for me when using with /proc or /sys files as needed for above script.
or I failed to understand what you are trying to tell, in that case please give example.

seth · 2017-03-06 19:39:39

Yes, I've however no problems w/ procfs or sysfs in general - never tried the LID device in particular, though.

hendry · 2017-03-07 08:05:23

Thanks Doc, your code snippet appears to be working. I've also since added it to my dotfiles: https://github.com/kaihendry/dotfiles/commits/master

Nonetheless I am concerned since my system feels vulnerable if I leave it running after unlocking the dm-crypted drive. Xorg + slock feels too vulnerable. MacOS does a much better job in this regard of locking down everything.

seth · 2017-03-07 08:27:36

SIGSTOP your session cg, unmount your encrypted device, re-lock it and reverse all that after exiting slock.
If you dm-crypted your OS partition, that of course won't work (but encrypting the OS is pretty useless anyway)

hendry · 2017-03-07 08:40:53

I do not agree it's useless. I really prefer whole whole partition encrypted purely to keep it simple.

Something could leak into an OS mount and then the whole point of encryption is bypassed.

Nonetheless linux sits on a decrypted vfat drive /boot. Be good if it could lock from that level.

Last edited by hendry (2017-03-07 08:41:13)

seth · 2017-03-07 13:44:53

That somehow sports the concept of a single user system - and probably require some interaction between kernel and display server (at least)
Sure OSX re-encrypts stuff (notably the OS) on merely screen-locking (you can run asecond user while the first users session is locked - unless you're actually talking about iOS)

If you want to harden things, notice the xorg settings for VT switching, zapping and grab killing/releasing shortcuts. You can also look into https://aur.archlinux.org/packages/physlock/ and of course you should stall the network and stop cron and at daemons.

Docbroke · 2017-03-07 13:56:48

from slock man page

SECURITY CONSIDERATIONS
     To make sure a locked screen can not be bypassed by switching VTs or killing the X server with Ctrl+Alt+Backspace,
     it is recommended to disable both in xorg.conf(5) for maximum security:

     Section "ServerFlags"
             Option "DontVTSwitch" "True"
             Option "DontZap"      "True"
     EndSection

seth · 2017-03-07 14:07:35

And just in case anybody reverts the defaults again ;-)

Option "AllowDeactivateGrabs" "False"
Option "AllowClosedownGrabs" "False"

hendry · 2017-03-09 03:29:35

seth wrote:

And just in case anybody reverts the defaults again ;-)

How do I check what are the defaults?

How do I test 'AllowDeactivateGrabs' & 'AllowClosedownGrabs' are wrongly enabled? I don't understand the exploit. Any pointers?

seth · 2017-03-09 07:03:16

run xprop (or anything that grabs the mouse, like a screensaver) and press Ctrl+Alt+Keypad-Multiply
If the option is disabled, the grabbing client is killed.

This is a developer feature (a hanging grab can be very nasty and easily caused when poking around), once some idiot considered a security flaw and removed it and then some other idiot added it back, but reversed the defaults and suddenly this was active on every desktop, allowing to just kill any screensaver.

Arch Linux

#1 2017-03-02 02:04:16

Integrating slock

#2 2017-03-02 06:52:57

Re: Integrating slock

#3 2017-03-06 16:30:02

Re: Integrating slock

#4 2017-03-06 16:54:08

Re: Integrating slock

#5 2017-03-06 17:43:21

Re: Integrating slock

#6 2017-03-06 19:39:39

Re: Integrating slock

#7 2017-03-07 08:05:23

Re: Integrating slock

#8 2017-03-07 08:27:36

Re: Integrating slock

#9 2017-03-07 08:40:53

Re: Integrating slock

#10 2017-03-07 13:44:53

Re: Integrating slock

#11 2017-03-07 13:56:48

Re: Integrating slock

#12 2017-03-07 14:07:35

Re: Integrating slock

#13 2017-03-09 03:29:35

Re: Integrating slock

#14 2017-03-09 07:03:16

Re: Integrating slock

Board footer