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/] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
