What is the minimum configuration to be able to interact with a dbus user session?

[ToBeReplaced]

Description

What is the minimum configuration to be able to interact with a dbus user session?

Steps to reproduce the issue:

podman run \
 -e DBUS_SESSION_BUS_ADDRESS="${DBUS_SESSION_BUS_ADDRESS}" \
 --mount "type=bind,$(printf "%s" "${DBUS_SESSION_BUS_ADDRESS}" | sed -e 's/unix:path=\(.\+\)/src=\1,dst=\1/')" \
 --security-opt label=disable \
 fedora:37 \
 bash -c 'dnf install -y dbus-tools && dbus-monitor'

Describe the results you received:

Failed to open connection to session bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Describe the results you expected:

A running dbus-monitor.

Additional information you deem important (e.g. issue happens only occasionally):

I have tried using --privileged as well, which fails in the same way. I would prefer not to use privileged once I understand what capabilities are missing.

Alternatively, mount /run/dbus/system_bus_socket and run dbus-monitor with --system to get the same issue another way.

journalctl -b0 | grep AVC after running does not show any denials (as expected).

My goal is not to run dbus-monitor; I am only using it here in this issue to demonstrate the problem as succinctly as I can.

Output of podman version:

Client:       Podman Engine
Version:      4.3.0
API Version:  4.3.0
Go Version:   go1.19.2
Built:        Fri Oct 21 08:09:51 2022
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.28.0
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.4-3.fc37.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.4, commit: '
  cpuUtilization:
    idlePercent: 99.32
    systemPercent: 0.11
    userPercent: 0.57
  cpus: 32
  distribution:
    distribution: fedora
    variant: coreos
    version: "37"
  eventLogger: journald
  hostname: redacted
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1001
      size: 1
    - container_id: 1
      host_id: 165536
      size: 65536
  kernel: 6.0.7-301.fc37.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 27805904896
  memTotal: 32744505344
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.6-2.fc37.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.6
      commit: 18cf2efbb8feb2b2f20e316520e0fd0b6c41ef4d
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1001/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.0-5.fc37.x86_64
    version: |-
      slirp4netns version 1.2.0
      commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 51h 5m 22.00s (Approximately 2.12 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /var/home/redacted/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 3
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/home/redacted/.local/share/containers/storage
  graphRootAllocated: 2029682122752
  graphRootUsed: 152555118592
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 29
  runRoot: /run/user/1001/containers
  volumePath: /var/home/redacted/.local/share/containers/storage/volumes
version:
  APIVersion: 4.3.0
  Built: 1666339791
  BuiltTime: Fri Oct 21 08:09:51 2022
  GitCommit: ""
  GoVersion: go1.19.2
  Os: linux
  OsArch: linux/amd64
  Version: 4.3.0

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

podman-4.3.0-2.fc37.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

Fedora CoreOS.

[vrothberg]

I am sure we're DBUS experts but we may be helpful in finding a solution. I suggest trying --privileged and then going through the various security mechanisms if it works with a privileged container.

@rhatdan wrote a nice blog on how to diagnose EPERMs and the proposed recipe may work here as well: https://www.redhat.com/sysadmin/container-permission-denied-errors

[ToBeReplaced]

--privileged causes no change. Nor does --net=host, --pid=host, or --ipc=host. Since we are root inside the container, user namespaces should not cause an issue, and this seems to be true because:

podman run -e \
  DBUS_SESSION_BUS_ADDRESS="${DBUS_SESSION_BUS_ADDRESS}" \
  --mount "type=bind,$(printf "%s" "${DBUS_SESSION_BUS_ADDRESS}" | sed -e 's/unix:path=\(.\+\)/src=\1,dst=\1/')" \
  --privileged --rm \
  fedora:37 \
  bash -c 'ls -lah "${DBUS_SESSION_BUS_ADDRESS:10}"'
srw-rw-rw-. 1 root root 0 Dec  5 09:00 /run/user/1001/bus

So it looks like it should be dbus itself that is checking some attributes I'm not sure aware of, but I don't know what to look for or how to debug. One of those I-don't-know-what-I-don't-know kind of things.

[Luap99]

Try with --userns keep-id, that makes sure that the id outside matches the id inside the container.

[ToBeReplaced]

I'll mark this, but it can be a bit more sophisticated than that.

This works only insofar as the user in the container is compatible this way. In the above case (running as root), --userns keep-id is sufficient.

Suppose you do useradd unprivileged --uid 1001 --gid 1001 and had an external user with id 1000 and wanted to executed as user unpriveleged while still accessing dbus, I was unable to get --userns keep-id:uid=1001,gid=1001 to permit this, though that same userns incantation is sufficient to modify mounted directories owned by 1000 on the host.

So, it looks like there is something missing in the way that user namespaces get mapped in this case.

I attempted to use the idmap flag on the --mount as well, but just get an issue with mount_setattr. Perhaps there is something more to do there. If anyone figures that out, I am interested. In the meantime, I can rework the Containerfiles in question to not use their own user.

[Luap99]

Note the problem is not with podman, it is the dbus session that requires auth via uid. Podman can connect to dbus but it runs as uid 0 within the user namespace because it knows the real id on the host so it uses the correct one for authentication.
See the code here: https://github.com/containers/common/blob/567290d3d3b328bb3c77c8785a407f4d3926988b/pkg/cgroups/cgroups_linux.go#L422

So what you need to know is the correct uid on the host and make the dbus client use that one for auth. I don't think there is a way to get this from within the container so the only solution is --userns keep-id.

[ToBeReplaced]

!!!! Ah, that's incredibly clarifying! Thank you!

[gilliginsisland]

I am a few years late on this one, but you can read /proc/self/uid_map and /proc/self/gid_map to see the mapping within the container.