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

Bug #1604872 reported by Sebastien Bacher on 2016-07-20
50
This bug affects 8 people
Affects Status Importance Assigned to Milestone
AppArmor
Undecided
Unassigned
apparmor (Ubuntu)
High
Tyler Hicks
Xenial
High
Tyler Hicks

Bug Description

[Impact]

Systemd user sessions makes telepathy unhappy because access to /run/user/<nnn>/bus is denied

[Test Case]

$ sudo apt install dbus-user-session empathy

Restart the session (or reboot) and then start empathy:

$ empathy

In 16.04, you may need to set correctly DBUS_SESSION_BUS_ADDRESS before launching empathy:

$ DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" empathy

Without this bug fix, empathy fails with "Error contacting the account manager", and dmesg shows several denial messages like so:

[ 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

[Regression Potential]

None. The fix simply adds permissions to the dbus-session-strict abstraction. This change will not introduce any new AppArmor denials since policy is being loosened instead of being restricted.

Martin Pitt (pitti) wrote :

This is the upstream patch.

Changed in apparmor (Ubuntu):
status: New → In Progress
assignee: nobody → Martin Pitt (pitti)
tags: added: patch
Martin Pitt (pitti) on 2016-07-20
tags: added: systemd-session
summary: - dbus abstraction not compatible with dbus-user-session
+ Apps can't connect to the user's session bus, even though it exists
Changed in apparmor (Ubuntu):
importance: Undecided → High
Tyler Hicks (tyhicks) wrote :

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

Martin Pitt (pitti) wrote :

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

Tyler Hicks (tyhicks) wrote :
Changed in apparmor:
status: New → Fix Committed
Tyler Hicks (tyhicks) wrote :

I'll include this in my apparmor upload tomorrow.

Changed in apparmor (Ubuntu):
assignee: Martin Pitt (pitti) → Tyler Hicks (tyhicks)
Launchpad Janitor (janitor) wrote :

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

Changed in apparmor (Ubuntu):
status: In Progress → Fix Released
Tyler Hicks (tyhicks) on 2016-07-28
description: updated
Changed in apparmor (Ubuntu Xenial):
status: New → In Progress
importance: Undecided → High
assignee: nobody → Tyler Hicks (tyhicks)
Tyler Hicks (tyhicks) on 2016-07-28
description: updated
description: updated
Daniel van Vugt (vanvugt) wrote :

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

dino99 (9d9) wrote :

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

dino99 (9d9) wrote :

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

Martin Pitt (pitti) wrote :

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

dino99 (9d9) wrote :

@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.

dino99 (9d9) wrote :

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

Tyler Hicks (tyhicks) wrote :

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.

Tyler Hicks (tyhicks) wrote :

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

Tyler Hicks (tyhicks) wrote :

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"'.

tags: added: verification-done
dino99 (9d9) wrote :

@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"

Tyler Hicks (tyhicks) wrote :

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

Christian Boltz (cboltz) wrote :

Fixed in AppArmor 2.11

Changed in apparmor:
status: Fix Committed → Fix Released
Steve Beattie (sbeattie) wrote :

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.

Changed in apparmor (Ubuntu Xenial):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers