Bug 16746 - Creates an inactive session for gdm sessions
Summary: Creates an inactive session for gdm sessions
Status: RESOLVED FIXED
Alias: None
Product: ConsoleKit
Classification: Unclassified
Component: PAM module (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium minor
Assignee: william.jon.mccann
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-16 14:00 UTC by Martin Pitt
Modified: 2009-02-11 13:33 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Add "nox11" PAM module option (2.21 KB, patch)
2008-08-04 09:31 UTC, Martin Pitt
Details | Splinter Review

Description Martin Pitt 2008-07-16 14:00:08 UTC
I have installed pam-ck-connector (0.2.10) with the usual PAM configuration:

  session optional        pam_ck_connector.so debug

(which is run for both VT and gdm logins in Debian/Ubuntu).

However, gdm already has proper CK integration and registers its own seats for spawned sessions. Thus you end up with two sessions:

Session12:
        uid = '1001'
        realname = 'Joe,,,,'
        seat = 'Seat4'
        session-type = ''
        active = FALSE
        x11-display = ':20'
        x11-display-device = ''
        display-device = ''
        remote-host-name = ''
        is-local = TRUE
        on-since = '2008-07-16T20:42:53.887440Z'
Session13:
        uid = '1001'
        realname = 'Joe,,,,'
        seat = 'Seat1'
        session-type = ''
        active = TRUE
        x11-display = ':20'
        x11-display-device = '/dev/tty9'
        display-device = ''
        remote-host-name = ''
        is-local = TRUE
        on-since = '2008-07-16T20:43:01.226291Z'

The upper one is from pam-ck-connector (inactive, no DISPLAY), the lower one from gdm. With that, at least PolicyKit always considers the "worse" session type and does not give you any privileges which are restricted to foreground sessions (such as device permissions, admin programs, etc.)

I don't blame PK here, having two different sessions for the same x11-display is just confusing. It might be a problem in pam-ck-c of creating a session although gdm already did so (if gdm is first), or CK not replacing a session with a "better"/newer one (if gdm opens the CK session after PAM), or perhaps the inability of both to work together in general (and thus it isn't possible to have the very convenient "common-session" PAM configuration).

Do you have any insight here how to untangle this?

Thanks in advance!
Comment 1 william.jon.mccann 2008-07-30 15:15:41 UTC
Probably should not be using the CK PAM module in the stack that GDM uses.  I would recommend that you only use the PAM module for "login".
Comment 2 Martin Pitt 2008-07-30 22:57:59 UTC
Right, that indeed works better. I just wondered whether this can simply be declared as 'misconfiguration' or whether CK should handle this a little more gracefully in CK or also PK. However, that will become handwavy very quickly, I guess.

So feel freel to close this if you think there's nothing to be improved in CK.

Thanks, Martin
Comment 3 Martin Pitt 2008-08-04 09:31:28 UTC
Created attachment 18107 [details] [review]
Add "nox11" PAM module option

I pondered this problem from various angles now. Using /etc/pam.d/login is not a great solution for us (for various technical reasons),  ck_get_active_console_num() cannot be used in the PAM module (only linked to the client-side lib, and -sysdeps.c is only in the server), introducing Linux specific code into the PAM module is bad, and exclusively using the PAM module and disabling CK support in gdm doesn't work because then the PAM module doesn't get to know the real TTY.

Anyway, this is the solution I'd like to use now. It does not change the default behaviour, but adds an option "nox11" which will only create sessions for real VTs, not for X11 displays.

It's tiny, so I'm happy enough to maintain it as a patch in Ubuntu, but of course I'd welcome applying upstream. Thank you!
Comment 4 william.jon.mccann 2009-02-11 13:33:06 UTC
Hey, sorry for the long delay.  This seems reasonable.  I've committed this to master.  Thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.