LightDM - Jul 2015 - sd 221 regression: login - nonexistent sessions via lightdm

Revert "login: re-use VT-sessions if they already exist" - commit
0204c4b
http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b

$ loginctl
   SESSION        UID USER             SEAT
        c1        989 lightdm          seat0

1 sessions listed.

$ /usr/libexec/polkit-gnome-authentication-agent-1

(polkit-gnome-authentication-agent-1:2137): polkit-gnome-1-WARNING **: Unable to
determine the session we are in: No session for pid 2137

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$ loginctl 
   SESSION        UID USER             SEAT            
        c1        989 lightdm          seat0           
         1       1001 test             seat0           

2 sessions listed.

$ ps ux | grep [a]uth
test      1850  0.0  0.4 451460 15496 ?        Sl   17:56   0:00
/usr/libexec/polkit-gnome-authentication-agent-1


Properly settles xfce-session initialized via lightdm.
---
 src/login/logind-dbus.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 659ce18..640ae92 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -690,8 +690,6 @@ static int method_create_session(sd_bus_message *message,
void *userdata, sd_bus
         }
 
         manager_get_session_by_pid(m, leader, &session);
-        if (!session && vtnr > 0)
-                session = (vtnr < m->seat0->position_count) ?
m->seat0->positions[vtnr] : NULL;
         if (session) {
                 _cleanup_free_ char *path = NULL;
                 _cleanup_close_ int fifo_fd = -1;
-- 
2.4.5

Hi

On Tue, Jul 7, 2015 at 6:14 PM, poma <pomidorabelisima at gmail.com>
wrote:
>
> Revert "login: re-use VT-sessions if they already exist" - commit
0204c4b
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b
Can someone elaborate what exactly lightdm does here? We really want
to prevent multiple sessions on the same VT. This is just nasty and
never made any sense. So I'm really interested why lightdm doesn't
kill it's manager-session before it starts the new session. Any
particular reason here?

Furthermore, how exactly does lightdm do all this. Is there a control
daemon running outside the session, then there's the graphical login
processes with their own 'lightdm' session? Once the login is done,
you start the new session from the control daemon and _afterwards_
destroy the lightdm-session?

Thanks
David

On Wed, 8 Jul 2015 at 04:31 David Herrmann <dh.herrmann at gmail.com>
wrote:
> Hi
>
> On Tue, Jul 7, 2015 at 6:14 PM, poma <pomidorabelisima at gmail.com>
wrote:
> >
> > Revert "login: re-use VT-sessions if they already exist" -
commit 0204c4b
> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=0204c4b
>
> Can someone elaborate what exactly lightdm does here? We really want
> to prevent multiple sessions on the same VT. This is just nasty and
> never made any sense. So I'm really interested why lightdm doesn't
> kill it's manager-session before it starts the new session. Any
> particular reason here?
>
> Furthermore, how exactly does lightdm do all this. Is there a control
> daemon running outside the session, then there's the graphical login
> processes with their own 'lightdm' session? Once the login is done,
> you start the new session from the control daemon and _afterwards_
> destroy the lightdm-session?
>
>
If I follow the thread correctly the issue here is having two logind
sessions open using the same VT?

Yes, this can definitely happen in LightDM in the following case:

1. LightDM starts up
2. LightDM starts an X server on a free VT (e.g. 7)
3. LightDM starts a greeter process which connects to the X server. Via
libpam-systemd a logind session is opened.
4. User logs in via greeter.
5. LightDM stops the greeter by sending a SIGTERM to it.  The greeter
closes the PAM session which closes the logind session.
6. LightDM starts the user session. The existing X server is used so this
session is on the same VT as the greeter session was.

The issue is that after step 5 LightDM considers the greeter session to be
completely closed. However, it appears that closing the PAM session only
cases the logind session to be put into the "closing" state. As
pointed out
we have an issue where Unity Greeter isn't waiting for some of its child
processes before exiting and that is keeping the logind session open for a
short time. I think there's still a race here in any case because the
display manager just has no idea when the session is really closed.

I've been looking for the right way to handle this with logind since we
should be able to make the daemon completely aware of the state of the
session so we can avoid this. GDM as far as I can tell also doesn't appear
to check if the logind sesion is actually closed.

The check for the greeter is certainly a workaround for the particular
first login case as described above. The issue can also probably occur by a
misbehaving user session. i.e. logging out then in again could leave the
display manager thinking a VT is free while there are still logind sessions
open with that VT.

So the correct solution might be to just to ignore logind sessions in the
"closing" state when checking if a VT is used more than once.

Another option is to require display managers to ensure a logind session is
closed before reusing VTs. This would require more work and also is a
little bit weird in the traditional X case since the VT is actually owned
by the X server and not the session.

--Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/lightdm/attachments/20150707/066c83c3/attachment.html>