GNOME Bugzilla – Bug 685935
GDM won't start (ConsoleKit related?)
Last modified: 2012-10-16 15:47:03 UTC
Hi. I'm trying to port GDM 3.6.0 to OpenBSD. Obviously we don't have support for systemd so our GDM uses ConsoleKit. When trying to run it, it fails to start the greeter with the following error: gdm-simple-greeter[8217]: Gdm-DEBUG(+): GdmClient: connecting to address: unix:path=/tmp/dbus-0ARnDlle gdm-simple-greeter[8217]: WARNING: Unable to start greeter session: Could not connect: Permission denied And in the logs, I can see the following: dbus[13449]: [system] Rejected send message, 1 matched rules; type="method_call", sender=":1.19" (uid=0 pid=6342 comm="/usr/local/sbin/gdm-binary") interface="org.freedesktop.DBus.Properties" member="GetAll" error name="(unset)" requested_reply="0" destination=":1.20" (uid=0 pid=27824 comm="/usr/local/libexec/gdm-simple-slave") Is there any obvious or particular dbus/ConsoleKit configuration that should be modified for GDM to work without systemd? Any input would be greatly appreciated. Thanks!
So the way this works is the greeter uses libgdm to talk to the main gdm-binary process. It calls a system bus method called org.gnome.DisplayManager.OpenSession on the daemon's manager object. That method returns a private peer-to-peer address that the greeter can connect to, to do the private authentication communication. The messages above are saying it was able to call OpenSession and it got a result back, but when it tried to connect to that result it got permission denied. A few ideas: 1) Maybe the permissions on /tmp/dbus-0ARnDlle are wrong? 2) Maybe the allow_user_function in gdm-session.c is failing? Can you attach the full logs?
Hi Ray. Thanks a lot for the speedy reply! You can find the logs attached. One thing I forgot to mention is that the GDM 3.4 series worked without issue.
Created attachment 226342 [details] gdm greeter log
Created attachment 226343 [details] gdm slave log
and what are the file permissions on /tmp/dbus-q7cOL1fk ? Can you add a log statement to the allow_user_function in gdm-session.c to see if it's getting called and failing?
(In reply to comment #5) > and what are the file permissions on /tmp/dbus-q7cOL1fk ? Can you add a log > statement to the allow_user_function in gdm-session.c to see if it's getting > called and failing? This is the file permission: srwxr-xr-x 1 root wheel 0 Oct 16 09:56 /tmp/dbus-blnUBa6s I added some debug printf to allow_user_function() but it seems it does not even get called at this point...
so that's definitely the problem,the greeter doesn't have read access to the socket.
Created attachment 226555 [details] [review] gdm-dbus-util: make socket world accessible On Linux dbus server sockets are world readable and world writable since they're abstract. Access control is handled at client connection time. On platforms that don't support abstract sockets, dbus server sockets are owned by the user that creates them. This disparity in behavior means that GDM greeters can't connect to GDM on platforms that doesn't support abstract sockets (e.g. OpenBSD). This commit changes GDM to perform heuristics to detect the socket address for the non-abstract case and open up its permissions.
Created attachment 226556 [details] [review] gdm-dbus-util: don't try to generate abstract socket address ourselves GDM currently goes through gymnastics to generate the dbus socket address for peer-to-peer connections. GDBus already has magic for figuring out when to use abstract sockets and when not to, so this code is extraneous. This commit drops it.
Mind trying these patches and telling me if they fix things for you?
(In reply to comment #10) > Mind trying these patches and telling me if they fix things for you? Both patches applied... GDM now works beautifully! Awesome, thanks a lot Ray.
Thanks. I talked to davidz about this issue, and he's of the opinion fixing permissions in GDM is right versus fixing it in GDBus, so I've pushed these now.