core: add a greetd login backend

[PaideiaDilemma]

This MR allows hyprlock to function as a greeter.

Hyprlock would be usable as a login frontend for greetd as well as a wayland lockscreen application.

Some details:

• You need an additional minimal Hyprland config for running the greeter on top of (that one would be generic, so we can maybe provide it.)
• Hyprlock will run as the greetd user. That means all the label commands for example will run under a different user, who may not have access to some shell commands. It also means that your config for greetd login needs to be accessible by this user.
• You need to configure greetd to start hyprlock.

Currently only support a single static user.

TODO:

• verify and check that the greetd protocol handling is implemented correctly
• cleanup the session picker, add text align
• (-> use glaze) decide if the baked-in (not) json parser is good enough or if we want to use a real one (I started the implementation with glaze, then I wanted something simpler and threw together the included "NotJson" implementation that only parses strings and vectors of strings and does not support nested data.)
• documentation

Related issue: #564

[PaideiaDilemma]

@vaxerski @fufexan
Ping because this draft introduces a big feature and I want to check if you like it or not before doing moving on with the TODO's

[PaideiaDilemma]

This is my setup on nixos: https://github.com/PaideiaDilemma/dotnix/blob/main/host/sessions.nix
This comment describes how to set it up: #564 (comment)

[fufexan]

I personally use greetd autologin and have hyprlock as an exec-once in my hl config. I would use a proper greeter but the transition isn't seamless.

That being said, I'm not opposed to this change.

[vaxerski]

maybe consider adding pointer support first so that people can click on session entries

[PaideiaDilemma]

I would use a proper greeter but the transition isn't seamless.

Yeah there is always a gpu reset when starting the actual session.
That being said, probably quite hardware dependent. On my desktop with a 6650xt its quite smooth.

[vaxerski]

Yeah there is always a gpu reset when starting the actual session

a monitor modeset, not a gpu reset...

[fufexan]

Yeah there is always a gpu reset when starting the actual session. That being said, probably quite hardware dependent. On my desktop with a 6650xt its quite smooth.

I have the Ryzen 5800U iGPU. About the same generation, but launching is pretty choppy.

I'm curious how KDE/Gnome handle this with SDDM/GDM.

[Nicknamely]

Current status of this draft ? @vaxerski

edit: sorry for the ping. Thought this was years ago .

[vaxerski]

not my draft?

[VirtCode]

Been running this for the past week or so and it is so far working great on my end!

Would it be possible to add an option to preselect a session type, or even force a particular one? Didn't find such an option being there yet in the diff. I don't really want to show the session picker (as I only have a hl session) but at the moment it chooses the uwsm option by default which I don't even have installed. So it would be nice to be able to set which one is selected on startup.

And maybe we'd also want to disable the arrow keys for switching sessions if the session picker is not shown, so people don't accidentally change the session without noticing.

[PaideiaDilemma]

Would it be possible to add an option to preselect a session type, or even force a particular one? Didn't find such an option being there yet in the diff. I don't really want to show the session picker (as I only have a hl session) but at the moment it chooses the uwsm option by default which I don't even have installed. So it would be nice to be able to set which one is selected on startup.

Yep. Right now you can tell hyprlock where to search for wayland sessions (as .desktop files), but you can also manually specify a session in the config with login-session. I did add a login:default_session option. It supports using either the session name, when the session is configured via login-session, or a path to the desktop file that shall be the default.

And maybe we'd also want to disable the arrow keys for switching sessions if the session picker is not shown, so people don't accidentally change the session without noticing.

Good point! The session is now fixed at 0, or the default session if it's configured, when there is no session-picker widget in the config.

Next I will add click support and text align for the session-picker widget.
However, I have been questioning if the session-picker is the right abstraction.
Maybe it would be better to just have a session widget that specifies a user and a session, which is clickable.
That would make it easy to have a mutli-user setup, add an image widget to a certain session, etc.
The downside would be that the default behavior wouldn't show all the available sessions on your system like it does now by searching /usr/share/wayland-sessions. Let me know if someone has some thoughts about that.

[VirtCode]

Thanks for adding the default session option, can confirm that it works as expected.

Here's a couple of minor issues I noticed while testing my own config, but nothing breaking or really important:

• With this branch, hyprlock crashes on exit triggered with sigusr1. Don't know whether this also happens when exiting after a successful login as I don't have logs from that. Anyways, here's a backtrace I captured: hyprlock-greetd-sigusr-bt.txt
• The size given to session-picker:size seems to always behave as a percentage of the screen size even without specifying the % signs. I don't know whether I have missed something here but e.g. specifying size = 100, 100 I'd expect 100x100px but it fills the whole screen.
• When running hyprlock without the --greetd flag the session picker is shown, but only contains the sessions which are added with a login-session section. I don't know what the expected behaviour should be here though.

What also would be nice would be a proper way to test a greetd configuration, without having to go into a greetd session. I did my testing by running hyprlock --config hyprlock-greeter.conf --greetd and sleep 10 && pkill -10 hyprlock in two shells, which was quite clunky. I don't know whether there's already a better way to do this. Anyways, I have just noticed that the session picker is also shown when locking normally, so this would be a non-issue if file-based sessions were also shown when not in --greetd mode (see last point above).

However, I have been questioning if the session-picker is the right abstraction.

While I myself don't really plan on using a session picker, here's some ideas anyways. What I like about the session picker as it is currently implemented is how convenient it is. You can just add one widget to your config, tweak a couple of colors and have a nice looking and functional setup. So I'd suggest keeping it for that reason.

For users which might want something different or more customizable, we could do two things, 1. adding a new substitution variable which shows the currently selected session name, and 2. some kind of special keyword you could set an onclick property to, to change the session on click (either relatively or absolutely). I think this setup would be quite flexible, and it would be possible to do your session-widget by just using a label and that onclick keyword.

[MalpenZibo]

It works great! The only issue I found is that I'm unable to use the fingerprint when launched with --greetd. But it's not a problem because I don't plan to use it. When used without --greetd, it's impossible to unlock using the password, it works only with the fingerprint. It's something that with the "official" hyprlock arch package doesn't happen.

Right now, I have installed this version using nix.

[PaideiaDilemma]

@VirtCode @MalpenZibo Extra great feedback thanks!!!

I will address it soonish.

[PaideiaDilemma]

Sadly fingerprint won't work with greetd.
Maybe as an additional factor, or maybe with some hack, but generally the greetd server itself must decide on if we have authenticated successfully or not.

Thant being said, it's probably best. When you log in initially you shouldn't be able to use biometrics. That opens up a bunch of potential attacks.

[marlonmarcello]

Just gave this a try and I just wanted to say that you've been doing great work @PaideiaDilemma !
It worked really well, only thing for me was that I also experienced the crash issue that @VirtCode mentioned.
Looking forwards to this being on main, again, thanks for the work on it.

[pm4rcin]

Thant being said, it's probably best. When you log in initially you shouldn't be able to use biometrics. That opens up a bunch of potential attacks.

Just to add my 2c since systemd-homed will be integrated sooner or later to major distros it probably makes sense. You can then have a situation where only your $HOME is encrypted and the rest of system files are just verified cryptographically using e.g. fs-verity. So it would be something similar to Android Verified Boot (of course not as strong but still).

[PaideiaDilemma]

That has absolutely nothing to do with this PR and also no, even if you use systemd-homed, allowing fprint to be the only factor is not sufficiently secure. Idk about android in general, but at least grapheneos requires an actual password after bootup. It's not about verifying you are booting the correct system. Its about minimizing the risk of bypassing biometrics either with an electronics based attack, or with a fake fingerprint.

[PaideiaDilemma]

Update on the PR: Rebased and we now have click support for the session-picker and I think I fixed the crash @VirtCode mentioned.
Testing is welcome :)

[pm4rcin]

That has absolutely nothing to do with this PR and also no, even if you use systemd-homed, allowing fprint to be the only factor is not sufficiently secure. Idk about android in general, but at least grapheneos requires an actual password after bootup. It's not about verifying you are booting the correct system. Its about minimizing the risk of bypassing biometrics either with an electronics based attack, or with a fake fingerprint.

I agree with you and just wanted to expand your argument but I've skipped important parts since they were obvious to me. I'm fully aware of how GrapheneOS does it, it was just a mental shortcut you know. :D Anyway thanks for your work!

[Toniolo-Marco]

I would like to test your fork, but since I am new to NixOS and Hyprland, I don't know how to do it. I currently use SDDM and Hyprlock. I saw that you did something like:

# for greetd login via hyprlock
hyprlock-greetd = {
  url = "github:PaideiaDilemma/hyprlock?ref=greetdLogin";
  inputs.nixpkgs.follows = "nixpkgs";
  inputs.hyprlang.follows = "hyprland";
  inputs.hyprutils.follows = "hyprutils";
};

What other settings should I use? Thanks in advance.

Edit: which branch should I look at? cause it seems like in the last commit of greetdLogin you hard coded your user.