Bug#1039958: autopkgtest-build-podman: Image creation fails with "sd-bus call: Permission denied"

[Gioele Barabucci]

Package: autopkgtest
Version: 5.28
Severity: important
X-Debbugs-Cc: gio...@svario.it

Running `autopkgtest-build-podman --image debian:sid` always fails
during the last step:

```
STEP 13/13: RUN sh -eux /opt/autopkgtest/setup-testbed /
error running container: from /usr/bin/crun creating container for
[/bin/sh -c sh -eux /opt/autopkgtest/setup-testbed /]: sd-bus call:
Permission denied: Permission denied
```

This happens on a normal Bookworm machine running systemd, while I'm
logged in via ssh.

Logs:

```
$ autopkgtest-build-podman --image debian:sid
INFO:autopkgtest-build-docker:['podman', 'build',
'--build-arg=IMAGE=debian:sid', '--tag', 'autopkgtest/debian:sid',
'--build-arg=AUTOPKGTEST_APT_PROXY=', '
--build-arg=AUTOPKGTEST_KEEP_APT_SOURCES=yes',
'--build-arg=AUTOPKGTEST_SETUP_APT_PROXY=',
'--build-arg=AUTOPKGTEST_SETUP_VM_POST_COMMAND=true', '--build-ar
g=RELEASE=sid', '/tmp/tmpc1ehvx3t']
WARN[0000] The cgroupv2 manager is set to systemd but there is no
systemd user session available
WARN[0000] For using systemd, you may need to login using an user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl
enable-linger 1000` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs
STEP 1/13: FROM debian:sid
Resolved "debian" as an alias
(/etc/containers/registries.conf.d/shortnames.conf)
Trying to pull docker.io/library/debian:sid...
Getting image source signatures
Copying blob 2e79cba44192 done
WARN[0008] Trying to create a layer
"e214315965a2b5ccbd42ab67539d5233dbde9a7019d784610da872bfbd7e9a79" while
directory "/var/cache/podman/overlay/e214315965Copying blob 2e79cba44192
done
Copying config 4b2de9ef18 done
Writing manifest to image destination
Storing signatures
STEP 2/13: ARG AUTOPKGTEST_BUILD_DOCKER=1
--> b22e8c1c457
STEP 3/13: ARG AUTOPKGTEST_APT_PROXY=
--> 0501b566487
STEP 4/13: ARG AUTOPKGTEST_APT_SOURCES=
--> 760aa90c960
STEP 5/13: ARG AUTOPKGTEST_KEEP_APT_SOURCES=
--> bd1b696354d
STEP 6/13: ARG AUTOPKGTEST_SETUP_APT_PROXY=
--> d8461af9d71
STEP 7/13: ARG AUTOPKGTEST_SETUP_INIT_SYSTEM=
--> 0da0d497018
STEP 8/13: ARG AUTOPKGTEST_SETUP_VM_POST_COMMAND=
--> 360f99c572b
STEP 9/13: ARG AUTOPKGTEST_SETUP_VM_UPGRADE=
--> 253b6c84909
STEP 10/13: ARG MIRROR=
--> 614b5909df4
STEP 11/13: ARG RELEASE=
--> 4a7e36a1d8a
STEP 12/13: COPY setup-testbed /opt/autopkgtest/setup-testbed
--> d614a626cb0
STEP 13/13: RUN sh -eux /opt/autopkgtest/setup-testbed /
error running container: from /usr/bin/crun creating container for
[/bin/sh -c sh -eux /opt/autopkgtest/setup-testbed /]: sd-bus call:
Permission denied: Permission denied
: exit status 1
Error: building at STEP "RUN sh -eux /opt/autopkgtest/setup-testbed /":
while running runtime: exit status 1

$ loginctl list-sessions
SESSION UID USER SEAT TTY
2 1000 gioele pts/0

1 sessions listed.

$ loginctl user-status | head -n6
gioele (1000)
Since: Fri 2023-06-30 08:40:27 CEST; 22min ago
State: active
Sessions: *2
Linger: yes
Unit: user-1000.slice
```


-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-cloud-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii apt-utils 2.6.1
ii libdpkg-perl 1.21.22
ii procps 2:4.0.2-3
ii python3 3.11.2-1+b1
ii python3-debian 0.1.49

Versions of packages autopkgtest recommends:
ii autodep8 0.28
ii fakeroot 1.31-1.2

Versions of packages autopkgtest suggests:
pn docker.io <none>
pn fakemachine <none>
ii lxc 1:5.0.2-1
pn lxd <none>
pn ovmf <none>
pn ovmf-ia32 <none>
ii podman 4.3.1+ds1-8+b1
ii python3-distro-info 1.5
pn qemu-efi-aarch64 <none>
pn qemu-efi-arm <none>
pn qemu-system <none>
ii qemu-utils 1:7.2+dfsg-7
pn schroot <none>
ii util-linux 2.38.1-5+b1
ii vmdb2 0.27+really.0.26-1
ii zerofree 1.1.1-1

-- no debconf information

[Gioele Barabucci]

Control: block -1 by 1013344

autopkgtest-build-podman's failure is due to the issue reported in [1],
i.e. the Debian setup of podman requires `dbus-user-session`, but none
of the podman-related packages Depends on it.

[1] https://bugs.debian.org/1013344

--
Gioele Barabucci

[Simon McVittie]

On Fri, 30 Jun 2023 at 12:52:31 +0200, Gioele Barabucci wrote:
> autopkgtest-build-podman's failure is due to the issue reported in [1], i.e.
> the Debian setup of podman requires `dbus-user-session`, but none of the
> podman-related packages Depends on it.
>
> [1] https://bugs.debian.org/1013344

Is there anything that could or should be done in autopkgtest to resolve
this? The only thing I can see that would help from the autopkgtest side
would be a dependency on dbus-user-session, but the dependencies of the
various autopkgtest-build-* tools are only Suggests anyway (we consider
the core functionality of autopkgtest to be running tests, not setting
up any specific backend), and adding a Suggests on dbus-user-session
seems like it wouldn't be a particularly helpful hint for users that
the absence of dbus-user-session is why they're seeing this error.

If this isn't actionable from autopkgtest's side, then I think the best
thing would be to reassign this bug to podman, merge it with #1013344,
and give it an "affects" on autopkgtest so that it'll still show up in
our list of known issues.

smcv

[Gioele Barabucci]

On 30/06/23 21:15, Simon McVittie wrote:
> On Fri, 30 Jun 2023 at 12:52:31 +0200, Gioele Barabucci wrote:
>> autopkgtest-build-podman's failure is due to the issue reported in [1], i.e.
>> the Debian setup of podman requires `dbus-user-session`, but none of the
>> podman-related packages Depends on it.
>>
>> [1] https://bugs.debian.org/1013344
>
> Is there anything that could or should be done in autopkgtest to resolve
> this?

Perhaps unrelated to this specific bug, but I would suggest moving the
builder/drivers to their own packages (autopkgtest-podman,
autopkgtest-qemu) and letting them Depends on the required packages.

In this way, if I can be sure that after the installation of
autopkgtest-X I have all the things that are _needed_ to run that
specific driver.

> If this isn't actionable from autopkgtest's side, then I think the best
> thing would be to reassign this bug to podman, merge it with #1013344,
> and give it an "affects" on autopkgtest so that it'll still show up in
> our list of known issues.

That also seems reasonable.

--
Gioele Barabucci

[Faidon Liambotis]

On Fri, Jun 30, 2023 at 12:52:31PM +0200, Gioele Barabucci wrote:
> autopkgtest-build-podman's failure is due to the issue reported in [1], i.e.
> the Debian setup of podman requires `dbus-user-session`, but none of the
> podman-related packages Depends on it.

podman may not Depend on dbus-user-session, but it Recommends it. I
believe that is because podman may be used in a number of different
configurations some of which may require dbus-user-session, while others
may not.

Per Policy § 7.2, "The Recommends field should list packages that would
be found together with this one in all but unusual installations".
Basically, if you explicitly decide to not install a Recommends, it is
expected that certain configurations or functionalities of the package
break.

Therefore I don't see how this is a bug, rather than a misconfiguration.
Am I missing something?

Thanks,
Faidon

[Gioele Barabucci]

On 06/09/23 15:27, Faidon Liambotis wrote:
> On Fri, Jun 30, 2023 at 12:52:31PM +0200, Gioele Barabucci wrote:
>> autopkgtest-build-podman's failure is due to the issue reported in [1], i.e.
>> the Debian setup of podman requires `dbus-user-session`, but none of the
>> podman-related packages Depends on it.
>
> podman may not Depend on dbus-user-session, but it Recommends it.

Indeed this is not a `podman` issue, but a `autopkgtest-build-podman` one.

To rephrase it: autopkgtest-build-podman does not work without
dbus-user-session. Why doesn't the package that contains
autopkgtest-build-podman Depends: on dbus-user-session?

The answer is (I presume) that the package containing
autopkgtest-build-podman (autopkgtest) is a bit too generic to have an
hard Depend on dbus-user-session. This is why I was suggesting splitting
it into a separate package.

If there is consensus, I volunteer to create a MR to move
autopkgtest-build-podman and related files to a separate package that
can then Depends: on podman, dbus-user-session and all other packages
required to make it work out of the box.

Regards,

--
Gioele Barabucci

[Simon McVittie]

On Wed, 06 Sep 2023 at 19:35:46 +0200, Gioele Barabucci wrote:
> If there is consensus, I volunteer to create a MR to move
> autopkgtest-build-podman and related files to a separate package that can
> then Depends: on podman, dbus-user-session and all other packages required
> to make it work out of the box.

I don't think this is a good idea: this design would mean autopkgtest
needing to go through the NEW queue and be arbitrarily delayed by ftp
team review every time it gains a new optional backend with non-trivial
dependencies. (Currently that's: docker/podman, lxc, lxd, qemu, schroot,
plus perhaps some of the autopkgtest-build* tools have requirements that
are not the same as their corresponding autopkgtest-virt- backends.)

Also, autopkgtest-virt-docker and -virt-podman are the same script,
running in a different mode, with different dependencies, and the same
is true for their autopkgtest-build-* equivalents. Should the package
containing them depend on Docker, or Podman, or both, or use an "|"-group?
None of those possible answers really seems right to me.

The ftp team also seems unlikely to be impressed by a new binary
package for around 20K of scripts (plus man pages).

If you want to help with this, I think a better MR would be one to make
a-b-podman and a-v-podman log a user-comprehensible warning mentioning
dbus-user-session, if they are started in podman mode while the socket
$XDG_RUNTIME_DIR/bus doesn't exist.

(Or if you can figure out exactly what circumstances require
dbus-user-session, maybe even exit early with an error under those
circumstances - but I wouldn't want to get that wrong and prevent people
from using podman in a situation where actually it would have worked fine,
so please be conservative, or at least have some sort of --force option.)

smcv