Subject: bug#540: elogind unmounts /run/user/$UID tmpfs filesystem after logging in again

From: Frank <[email-masked]>
Date: Thu, 21 Jan 2021 15:19:55 +0100

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