Can you show the output of ls -Z /usr/local/bin/tuigreet?

I suspect that it's labeled as user_home_t and the transition from xdm_t is blocked. If that's the case, restorecon -Fv /usr/local/bin/tuigreet should fix the problem.

These do not need to be set before pam_open_session, so in the spirit of simplicity, these should be handled as arbitrary environment vars set by a wrapper script (or even just by doing e.g. XDG_CURRENT_DESKTOP=blah command).

While I have a preference towards things that work out of the box despite being minimalistic and customizable, I get your point. It's just that from a distribution maintainer's standpoint wrapper scripts are kind of... not the best possible solution :(

Note that XDG_SESSION_TYPE and all other logind XDG_* vars are not related to freedesktop specifications, but are purely systemd-internal variables with very unfortunate names, and no intention from systemd to upstream it to freedesktop.

XDG_CURRENT_DESKTOP is mentioned in fd.o specs though. Which makes even less sense for me as it makes fd.o specs depend on internal systemd/Gnome things and decisions. Nevertheless, let's forget about it.

In the end, I guess we don't really have to add a generic variable support. Having a way to set session type should be enough, which may or may not be implemented as an environment variable in the protocol.

Certain environments (Gnome...) really want their XDG_SESSION_TYPE to be right:

gnome-shell[2741]: Failed to create backend: Could not get session ID: Session '14' is not a graphical session (type: 'tty')

There are also things that require XDG_CURRENT_DESKTOP, and according to the freedesktop spec it is a responsibility of the login manager to define it.

While supporting those in greetd is definitely non-goal, it might be worthy to allow greeter to support whatever freedesktop specifications they want to support.

For security considerations, allowed vars could be filtered (^XDG_).

If pam stack returns failure for the initial session user, greetd terminates, restarts and attempts to start initial session again. That would fail again and the sequence would continue until systemd decides that it's enough.

A fix for #10 would mitigate that, but I had an expectation that the authentication failure of initial session should simply cause greetd to proceed to the default session.