dbus blocking all graphical logins

[Kevin O'Gorman]

After a shutdown to do some standalone gparted tweaking (extend /home partition), the system was unable to log in any user graphically. Even a new user added after this began. Non-graphical logins via C_A_F1 were unaffected (which is how I was able to add a new user). X seemed okay in that the login screen showed as normal, but after entering the password, the screen would go black for a few seconds and go back to the login dialog.

Xorg logs appear normal.

On first going to console mode, there's a message from DBus indicating a disconnect from "Plymouth" -- whatever that is, and auth log has activity that suggests dbus involvement. Typical episode:

Dec 24 18:28:15 treat lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Dec 24 18:28:15 treat lightdm: pam_unix(lightdm:session): session opened for user kevin by (uid=0)
Dec 24 18:28:15 treat lightdm: pam_ck_connector(lightdm:session): nox11 mode, ignoring PAM_TTY :0
Dec 24 18:28:15 treat lightdm: pam_unix(lightdm:session): session closed for user kevin
Dec 24 18:28:16 treat lightdm: pam_unix(lightdm-greeter:session): session opened for user lightdm by (uid=0)
Dec 24 18:28:16 treat lightdm: pam_ck_connector(lightdm-greeter:session): nox11 mode, ignoring PAM_TTY :0
Dec 24 18:28:16 treat dbus[1637]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.30
" (uid=110 pid=3278 comm="/usr/sbin/lightdm-gtk-greeter ") interface="org.freedesktop.DBus.Properties" member="GetAl
l" error name="(unset)" requested_reply="0" destination=":1.13" (uid=0 pid=2260 comm="/usr/sbin/console-kit-daemon -
-no-daemon ")
Dec 24 18:28:17 treat lightdm: pam_succeed_if(lightdm:auth): requirement "user ingroup nopasswdlogin" not met by use
r "kevin"

I was only able to fix this by doing a fresh install. It happens I didn't mind stepping up to Saucy, and I have the disk space to leave the Raring root and home directories untouched. So I can get further information, or even try again.

The reasons I think of this as a bug rather than my own possible damage:
1) I've been doing this a very long time and I'm usually pretty careful; this time I was well within my expertise.
2) There was nothing unusual in the gparted run, and there does not appear to be any damage to any partition. Saucy has no problems with logins.
3) There is insufficient information in the logs for me to even guess where to start poking at a solution
4) In the ubuntu forum, I got a response from at least one other user (less of a tinkerer than I am) who's run into this or something like it and who also had to do a complete reinstall.

I wonder if something can be done about (3) above. For starters, that message about Plymouth may or may not be related. In the lightdm.log, there's mention of Plymouth that's a little different from what I see in Saucy, but it's only at the startup in both cases, not something that repeats with login attempts.

In Raring, where the error is, lightdm.log has this sequence early:[+0.00s] DEBUG: Starting local X display
[+0.00s] DEBUG: X server :0 will replace Plymouth
[+0.02s] DEBUG: Using VT 7
[+0.02s] DEBUG: Logging to /var/log/lightdm/x-0.log
[+0.03s] DEBUG: Writing X server authority to /var/run/lightdm/root/:0
[+0.03s] DEBUG: Launching X Server
[+0.03s] DEBUG: Launching process 1229: /usr/bin/X :0 -core -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtsw
itch -background none
[+0.03s] DEBUG: Waiting for ready signal from X server :0
[+0.03s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.03s] DEBUG: Registering seat with bus path /org/freedesktop/DisplayManager/Seat0
[+1.80s] DEBUG: Got signal 10 from process 1229
[+1.80s] DEBUG: Got signal from X server :0
[+1.80s] DEBUG: Stopping Plymouth, X server is ready
[+1.83s] DEBUG: Connecting to XServer :0
[+1.83s] DEBUG: Starting greeter

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: dbus 1.6.12-0ubuntu10
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
Date: Wed Dec 25 11:42:13 2013
InstallationDate: Installed on 2013-12-25 (0 days ago)
InstallationMedia: Xubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016)
MarkForUpload: True
SourcePackage: dbus
UpgradeStatus: No upgrade log present (probably fresh install)

[Seth Arnold (seth-arnold)]

Just for confirmation -- the ubuntu-bug attached files here are from Saucy, but the bug happened under Raring, correct?

The dbus version listed in the Dependencies.txt file would certainly have the ability to block specific dbus-messages via AppArmor configuration; the version in Raring should not have had that ability, unless you were playing around with pre-release AppArmor packages. Of course there's some policy mechanisms in pre-Saucy Dbus as well, but I'm much less familiar with that...

For information on the Saucy AppArmor Dbus integration, check out http://penguindroppings.wordpress.com/2013/10/18/application-isolation-with-apparmor-part-iii/

Since you've still got your Raring install around, it'd be nice to know the version of the dbus, apparmor, and linux-image* packages installed, and logging from the /var/log/syslog at the time of a failed login attempt. That'll help us figure out where to place the blame.

Thanks

[Launchpad Janitor (janitor)]

[Expired for dbus (Ubuntu) because there has been no activity for 60 days.]