| Summary: | Creates an inactive session for gdm sessions | ||
|---|---|---|---|
| Product: | ConsoleKit | Reporter: | Martin Pitt <martin.pitt> |
| Component: | PAM module | Assignee: | william.jon.mccann |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Add "nox11" PAM module option | ||
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". 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 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! 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.
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!