[systemd-devel] How is GDM supposed to register with systemd-logind? (aka udev 173 causes gnome fallback session)

[Colin Guthrie]

Hi,

I've run into a problem after the latest udev update.

Is GDM just supposed to use only PAM config[1] to register with
systemd-logind? If so, it's either broken or I've ballsed something up
(more than likely!)

The problem I'm getting is thus:

With udev 172, udev-acl would apply ACLs to devices (such as the DRI
device) when console-kit registers a new session.

This included the gdm user at the login manager stage.

Am I right in saying that now that systemd is taking over the
application of ACLs from CK, this means that GDM has to be registered
with logind for it to get appropriate ACLs written? If so, this is my
problem as gdm does not show up in systemd-loginctl output.


With udev 172, both systemd and console-kit would trigger ACL writes,
and as gdm is registered with CK, it got it's ACL written via that
route. Where as my normal user (which registered with CK and logind)
probably got ACLs twice.

Now this is where the problem arises. With udev 173, I believe that
udev-acl knows whether or not systemd is running and if it is, it it
won't write the ACLs. This means that even tho' gdm is still registered
with CK, this will never actually trigger an ACL write.

This means that gdm does not have access to /dev/dri/card0 and thus
cannot determine if the system is capable of 3D accel. This then sets an
atom on the root window which the gnome-session-check-accelerated binary
looks for. This atom acts as a little cache. If it doesn't exist, it
does a full probe and then writes the atom. The next time it runs it
finds the atom and skips the actual checks. But as the atom was written
by gdm when it couldn't access dri, it says no accel is available, even
although the user can actually access it and thus the gnome session is
set to fallback mode.

I have confirmed that by hacking out the check for the atom in
gnome-session-check-accelerated program allows me to login properly into
gnome-shell as it performs all the necessary checks every time, ignoring
the atom.


So, long story short, how is this supposed to work? :)

Apologies if this has been covered before, but I couldn't find any
reference on the list about it.

Thanks

Col


1. My gdm pam file looks pretty much identical to the fedora one (at
least the one from the package in git) but sans the selinux stuff:

#%PAM-1.0
auth       required    pam_env.so
auth       required    pam_succeed_if.so user != root quiet
auth       sufficient  pam_succeed_if.so user ingroup nopasswdlogin
auth       substack    system-auth
auth       optional    pam_gnome_keyring.so
account    required    pam_nologin.so
account    include     system-auth
password   include     system-auth
session    required    pam_loginuid.so
session    optional    pam_console.so
session    optional    pam_keyinit.so force revoke
session    required    pam_namespace.so
session    optional    pam_gnome_keyring.so auto_start
session    include     system-auth



system-auth contains:
#%PAM-1.0

auth        required      pam_env.so
auth        sufficient    pam_tcb.so shadow nullok prefix=$2a$ count=8
auth        required      pam_deny.so

account     sufficient    pam_tcb.so shadow
account     required      pam_deny.so

password    required      pam_cracklib.so try_first_pass retry=3
minlen=4  dcredit=0  ucredit=0
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow
nullok prefix=$2a$ count=8
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session     required      pam_tcb.so
-session     optional      pam_systemd.so






-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]