GNOME Bugzilla – Bug 685498
Aborts if accounts database can't be read
Last modified: 2012-10-08 08:57:01 UTC
Created attachment 225814 [details] stacktrace This is a bug that I originally filed on Launchpad. See https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1059233 if you want to follow the exciting path that the issue has taken so far. :-) Ubuntu ships an apparmor policy by default that restricts the paths that mission-control-5 (the binary) can access, including restrictions to the files in the home dir. The problem is that by default this is restricted to /home/*/.config/... Meaning that users with a different home directory or, in my case, a home directory which is a symlink to another part of the filesystem, get EACCES when libaccounts-glib tries to open the database. This manifests itself in the UOA mc-plugin receving a NULL pointer when calling ag_manager_new_for_service_type at ubuntu-online-accounts/mc-plugin/mcp-account-manager-uoa.c:356. This is then passed to the constructor of empathy_webcredentials_monitor in ubuntu-online-accounts/mc-plugin/empathy-webcredentials-monitor.c, which then segfaults due to the assertion failure at line 91. I don't think there's anything that UOA can do about not being able to access the accounts database. It just has to not segfault, but to fail gracefully instead. Trace attached.
Oops, I said segfault but that's not true. The program aborts with SIGABRT due to the assertion failure.
Created attachment 225871 [details] [review] deal if ag_manager_new_for_service_type() returns NULL Looks like it may happen because of Ubuntu's apparmor policy. We can't do much in this case but best to not crash MC at least.
Cheers. It resolves the crash for me. Empathy then gets into a confusing state where you can spawn the UOA dialog which shows all of your accounts but it doesn't know about or connect to any of them. I doubt it's worth spending any effort on this edge case though.
I'm not sure it will deal with having self->priv->manager being NULL afterward. I would add a g_return_if_fail (self->priv->manager != NULL) in all exposed functions to be safe. Maybe there is a way to tell MC to unload the plugin completely?
Created attachment 226019 [details] [review] deal if ag_manager_new_for_service_type() returns NULL Looks like it may happen because of Ubuntu's apparmor policy. We can't do much in this case but best to not crash MC at least.
Yeah, seems safer like that IMO. +1
Attachment 226019 [details] pushed as 63c548d - deal if ag_manager_new_for_service_type() returns NULL