Dbus-run-session not working with core18

snapd
1

Following How to use dbus-run-session on ubuntu core dbus-run-session should be working. Unfortunately it seems to me that something is missing here at least on core18 to actually have it work with confinement.

Example: https://github.com/apachelogger/sitter-dbus-session-test

Fails with:

Failed to open connection to "session" message bus: Failed to determine seats of user "1000": Permission denied

Which seems to be caused from not being able to talk to logind despite being able to access the seats
directory.

@jdstrand am I doing it wrong or is this indeed a bug?

I feel like I should perhaps also point out that without unity7 and desktop-legacy this actually works even less dbus-daemon[21857]: Failed to start message bus: Failed to bind socket "snap.sitter-dbus-session-test./dbus-0T5FytBxiy": Operation not permitted. I suppose that is somewhat expected?

Relevant dbus code
https://gitlab.freedesktop.org/dbus/dbus/blob/master/dbus/dbus-userdb-util.c#L56

2

Any AppArmor related messages in dmesg/journal?

3

Ah yes indeed

Jän 18 10:45:31 ajax audit[8016]: AVC apparmor="DENIED" operation="open" profile="snap.sitter-dbus-session-test.sitter-dbus-session-test" name="/proc/8016/mounts" pid=8016 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Jän 18 10:45:31 ajax audit[8016]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=7fac03a15082 a2=80000 a3=0 items=0 ppid=8015 pid=8016 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=6 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" key=(null)
Jän 18 10:45:31 ajax audit: PROCTITLE proctitle=646275732D6461656D6F6E002D2D6E6F666F726B002D2D7072696E742D616464726573730034002D2D636F6E6669672D66696C65002F736E61702F7369747465722D646275732D73657373696F6E2D746573742F7831342F73657373696F6E2E636F6E66
Jän 18 10:45:31 ajax audit[8016]: AVC apparmor="DENIED" operation="open" profile="snap.sitter-dbus-session-test.sitter-dbus-session-test" name="/usr/share/dbus-1/services/" pid=8016 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jän 18 10:45:31 ajax audit[8016]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55ceaef8f8d0 a2=90800 a3=0 items=0 ppid=8015 pid=8016 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=6 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" key=(null)
Jän 18 10:45:31 ajax audit: PROCTITLE proctitle=646275732D6461656D6F6E002D2D6E6F666F726B002D2D7072696E742D616464726573730034002D2D636F6E6669672D66696C65002F736E61702F7369747465722D646275732D73657373696F6E2D746573742F7831342F73657373696F6E2E636F6E66
Jän 18 10:45:31 ajax audit[8016]: AVC apparmor="DENIED" operation="open" profile="snap.sitter-dbus-session-test.sitter-dbus-session-test" name="/run/systemd/users/1000" pid=8016 comm="dbus-daemon" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jän 18 10:45:31 ajax audit[8016]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=55ceaef95620 a2=80000 a3=0 items=0 ppid=8015 pid=8016 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=6 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" key=(null)

Only the open call on /run/systemd/users/1000 should be the cause of the problem.

The first call is something Jamie already noticed when originally implementing support. The second call is simply trying to find services in the standard service dir (which is one of many possible locations).

4

Hi @sitter, have you find a solution for this problem? I have the same exact problem.

5

Nope, unfortunately not using strict confinement is the only way to deal with this for now.

1 Like
6

I apologize for the delay (just saw this now). I don’t have anything to report at this time but have added this to the list of things to investigate with 2.40 policy updates.

7

FYI, in addition to plugging network-bind for the syscalls, these are the rules that are needed:

/usr/share/dbus-1/services/{,*} r,
/usr/share/dbus-1/system-services/{,*} r,
/run/systemd/users/[0-9]* r,

The last one doesn’t give away anything more (that is meaningful) than what is in /etc/passwd, which is already allowed, so that will go to the default template. I’ll think about the other two.

8

FYI, https://github.com/snapcore/snapd/pull/7019