2022-08-05 Building a crappy cheap LightDM 1/?
This is a lightly edited mind dump, don't expect a well written post here.
What it is, does and why I built it
The goal of this little project was to build a collection of tools that is able to switch between two sessions on a Linux system for the purpose of having a session for working and one for logging in and unlocking the screen, the way it is implemented is by changing virtual terminals to the corresponding session when certain state-changes occur, much like LightDM and the light-locker.
The reason I'm doing this is because I want to be able to replace my currently pretty barebones screenlockers with a rich screenlocker that is able to do more than just showing me an unlock form, mostly for my phone but also for my other machines.
Why not just use LightDM?
Maybe oversimplified answer: I have the opinion that LightDM isn't great on mobile.
The core of this contraption are two instances of greetd, one for
actually logging in and one for giving me a properly set up
session to run my compositor in which could be replaced by an
instance of tinydm on my phone. These two communicate by
always running one of two scripts the locker and the
unlocker, both grab the current vt with the
command, write to pidfiles and
kill each other
and run hooks on exit.
Please Note: For my current
implementation the user that runs the logged in session needs
passwordless sudo access to the
chvt command, in
a multiuser scenario this may not be the best idea.
Unlocking works by entering your credentials in the
greeter, triggering the
unlock script which
SIGUSR1 to the locker process (using the
pidfile), and then entering a sleep loop waiting for the next
lock script handles this
SIGUSR1 by killing the lockscreen (in my case
swaylock) and using
chvt to switch the currently
active terminal to the one of the real-work-session.
Locking works almost exactly the reverse way as unlocking.
lock script starts the screenlocker, kills
the unlocker, this time with an ordinary
and starts waiting for being unlocked.
chvt to grab
the vt with the greeter on it and exits telling greetd to
start the greeter session for the next unlock.
To solve our little problem of how to bootstrap this thing
there is also an
initial-session-lock, a script
that writes its pid to the lockers pidfile and only exits
with a success code when it receives a
to act as a trigger for starting the session on the first
unlock. For shutting down my current solution is to wrap this
in a loop and kill the unlocker after sway exits.
Currently this is an experiment I've run on my personal dotfiles so the sources are not really in any central location yet and you probably don't want to just copypasta my scripts.
As mentioned above I have two instances of greetd running, one that starts the unlocker on login and one that starts the actual session.
The one starting the actual session could be replaced by
tinydm as I only care about the
autostarting part and that the environment is properly set up
so I don't have to do it myself here.
The following snippet placed in a file in
/etc/sudoers.d/ will give everyone in the
wheel group (the group that has sudo access
anyways, may also be called
sudo on some
systems) the permission to run
having to enter a password.
%wheel ALL= NOPASSWD: /usr/bin/chvt
Almost EOF …
More or less obviously this is very hacky, has multiple issues and falls apart very easily, somewhere in the next few months I'll try to find a cleaner way to implement this without relying on too much on shell scripting and firing signals at processes using pidfiles.
Until that happens I'll continue to use my sxmo screenlocker on my phone because it mostly works well enough for what I need.