Hi Mark,

Cmd "loginctl session-status" shows that class "greeter" is a property
of service "slim". It looks fine to me since slim does not fork a helper
process like, for example, lightdm does.

XDG_SESSION_CLASS is set by PAM module pam_elogind.so. Unsetting
XDG_SESSION_CLASS / changing it to "user" again before pam.open_session
breaks the fix. Overriding the environment variable by adding
"pam.setenv("XDG_SESSION_CLASS", "greeter");" to app.cpp (line 560)
won't change the class, just the variable (see below).

----------------- snip ---------------
devuan@devuan:~$ loginctl session-status | grep Service; set | grep 
XDG_SESSION
     Service: slim; type x11; class greeter
XDG_SESSION_CLASS=user
XDG_SESSION_ID=1
XDG_SESSION_TYPE=x11
----------------- snip ---------------

I did a quick check in the logind source code and as far as I can see a
greeter session does not have any additional privileges compared to a
user session. There is only have_multiple_sessions() in logind-dbus.c
that checks if there are multiple sessions; greeter sessions are not
counted.

Slim is a single process (class "greeter") without a helper (class
"user"). Changing the class to greeter is the best you can do.

Regards,
Frank

Mark Hindley schreef op 2021-01-21 11:00:
> It certainly makes sense for the slim login screen to be greeter class.
> But,
> semantically, I would also expect the subsequent user login to be class
> user. I
> don't yet know what other effects (if any) having the user login as
> class
> greeter has.
>
> Maybe we unset XDG_SESSION_CLASS again before pam.open_session? But
> maybe that
> would no longer fix the issue you came across?
>
>> Writing Display Managers (HOWTO):
>> https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/
>
> This seems to confirm that the user login itself should not be class
> greeter.
>
> Mark