Apps can't connect to the user's session bus, even though it exists

This is the upstream patch.

Can you paste in the denial for this issue (logged to /var/log/syslog)?

This is very simple to reproduce: In yakkety:

  sudo apt install dbus-user-session empathy

Restart the session (or reboot), start empathy. It fails with "Error contacting the account manager", and dmesg shows several

[ 63.960358] audit: type=1400 audit(1469458539.595:27): apparmor="DENIED" operation="connect" profile="/usr/lib/telepathy/mission-control-5" name="/run/user/1000/bus" pid=4563 comm="mission-control" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000

http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3492

I'll include this in my apparmor upload tomorrow.

This bug was fixed in the package apparmor - 2.10.95-4ubuntu2

---------------
apparmor (2.10.95-4ubuntu2) yakkety; urgency=medium

  * Drop the following change now that click-apparmor has been updated:
    - Continue installing aa-exec into /usr/sbin/ for now since
      click-apparmor's aa-exec-click autopkgtest expects it to be there
  * debian/patches/allow-stacking-tests-to-use-system.patch,
    debian/patches/r3430-allow-stacking-tests-to-use-system.patch: Replace
    patch with the final version that landed upstream and annotate the patch
    headers accordingly
  * debian/patches/r3460-ignore-file-events-with-send-or-receive-request.patch:
    Prevent an aa-logprof crash by ignoring file events that contains
    send or receive in the request mask. (LP: #1577051, LP: #1582374)
  * debian/patches/r3463-r3475-change-profile-exec-modes.patch: Allow policy
    authors to specify if the environment should scrubbed during exec
    transitions allowed by a change_profile rule. (LP: #1584069)
  * debian/patches/r3478-make-overlapping-safe-and-unsafe-rules-conflict.patch:
    Make sure that multiple change_profile rules with overlapping safe and
    unsafe exec modes conflict when they share the same exec conditional
    (LP: #1588069)
  * debian/patches/r3479-create-fcitx-abstractions.patch: Include fcitx and
    fcitx-strict abstractions that fcitx client profiles can reuse.
  * debian/control: Do a conffile move of /etc/apparmor.d/abstractions/fcitx
    from the fcitx-data to apparmor by setting up the correct Breaks and
    Replaces.
  * debian/patches/r3480-create-mozc-abstraction.patch: Include a mozc
    abstraction that mozc client profiles can reuse.
  * debian/patches/r3488-r3489-fix-racy-onexec-test.patch: Fix racy regression
    test so that the kernel SRU process is not interrupted by the onexec.sh
    periodically failing
  * debian/patches/r3490-utils-handle-change-profile-exec-modes.patch: Update
    the Python utilities to handle the new exec mode keywords in
    change_profile rules. (LP: #1584069)
  * debian/patches/r3492-allow-dbus-user-session-path.patch: Allow read/write
    access to the dbus-user-session socket file. (LP: #1604872)

 -- Tyler Hicks <email address hidden> Tue, 26 Jul 2016 23:03:05 -0500

Even with the fix GTK apps under Xmir are hung trying to connect to the wrong dbus address. Moved that to bug 1604704.

Still get the error on yakkety with the latest apparmor 2.10.95-4ubuntu2

dbus-update-activation-environment: error: unable to connect to D-Bus: Failed to connect to socket /tmp/dbus-S7lUkEeXo9: Connection refused

Should be nice to test with the newer dbus version from Debian Unstable too
http://metadata.ftp-master.debian.org/changelogs//main/d/dbus/dbus_1.10.8-1_changelog

@dino99: How exactly do you reproduce this? I. e. with which program gets the violation? Calling dbus-update-activation-environment in general certainly works.

@Martin

this is logged once with each cold boot only.
I suppose the "too long time loading X" seen after lightdm password validation, could be related with this logged message.

I have browsed the net about that issue, and many distros are affected, or have been affected.
Most comments are related to some dbus changes (some time back).
I have not more explanations about it.
But glancing at ./cache/upstart/gnome-settings-daemon.log, there is an error spamming it.

#11 adds:
this is with a gnome-shell session on yakkety 64 bits, with gnome3-staging ppa packages.

I've thoroughly tested apparmor 2.10.95-0ubuntu2.2 in xenial-proposed. I've verified that this bug is fixed (via the Test Case in the description) and I've also went through the AppArmor Test Plan (excluding the Ubuntu Touch specific tests):

  https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor

The Test Plan includes running the entire set of upstream AppArmor tests, a number of integration tests, libvirt tests, LXC/LXD tests, docker.io tests, Snappy confinement tests, etc.

Bah! My apologies for comment 13. I accidentally left that comment in the wrong bug report.

My apologies once again. Comment 13 was accurate. I got confused by some of the recent comments and thought I was looking at the wrong bug report.

I don't think that dino99's issues are related to the original AppArmor denials mentioned in the bug description and the presence of the gnome3-staging ppa package also complicate things a bit. dino99, are you seeing any AppArmor denials in /var/log/syslog? Denial messages will contain 'apparmor="DENIED"'.

@Tyler

apparmor logs seems good; like that example:

audit: type=1400 audit(1470130477.689:35): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/lightdm/lightdm-guest-session" pid=20307 comm="apparmor_parser"

That apparmor="STATUS" message simply means that the /usr/lib/lightdm/lightdm-guest-session AppArmor profile was loaded. Nothing to worry about there.

Fixed in AppArmor 2.11

This issue was fixed in Ubuntu 16.04 LTS in apparmor 2.10.95-0ubuntu2.2 (by way of 2.10.95-0ubuntu2.1, which was superceded in xenial-proposed). Marking that task closed.