[pkg-apparmor] Bug#1100135: Conflict between Podman Profile and Pasta profile breaks rootless network shutdown

[Sam Hartman]

package: apparmor
version: 4.1.0~beta5-3
severity: important
x-debbugs-cc: podman at packages.debian.org, pasta at packages.debian.org, golang-github-containers-common at packages.debian.org, tim.miller at hadronindustries.com

Recently I started running into the following error shutting down
containers with podman stop:

	* rootless netns: kill network process: permission denied
        This error is produced by
        golang-github-containers-common/libnetwork/internal/rootlessnetns/netns_linux.go
        in the cleanup function:
        	if err := n.cleanupRootlessNetns(); err != nil {
		multiErr = multierror.Append(multiErr, wrapError("kill network process", err))
	}

And that function effectively just finds and kills the pasta or
slirp4netns process:
	if err == nil {
		// kill the slirp/pasta process so we do not leak it
		err = unix.Kill(pid, unix.SIGTERM)
		if err == unix.ESRCH {
			err = nil
		}

Looking at my kernel logs, I see that
[  462.337636] audit: type=1400 audit(1741711021.533:118): apparmor="DENIED" ope
ration="signal" class="signal" profile="pasta" pid=4552 comm="exe" requested_mas
k="receive" denied_mask="receive" signal=term peer="podman"
In other words, apparmor is preventing podman from cleaning up pasta.

Podman is effectively supposed to be unconfined:
Quoting /etc/apparmor.d/podman:
# This profile allows everything and only exists to give the
# application a name instead of having the label "unconfined"

Although it turns out it's not really true that  podman can do anything
because it turns out that the base abstraction specifically special
cases the unconfined profile:
(quoting /etc/apparmor.d/base)

  # Allow unconfined processes to send us signals by default
  signal (receive) peer=unconfined,

  # Allow us to signal ourselves
  signal peer=@{profile_name},

  # Checking for PID existence is quite common so add it by default for now
  signal (receive, send) set=("exists"),


So, in other words, podman could send the signal if it were in the
unconfined profile, but cannot because it has a profile at all.

There's clearly a race condition involved somewhere. Some of my
containers exhibit this behavior, but some do not.
However, once it starts happening, it keeps happening, and it is common
enough that it is breaking a lot of automation.



On the apparmor side, I'd like to either see the bogus/empty podman
profile removed   or to see signals from podman permitted by the pasta
profile.
I also think that golang-github-containers-common should treat EACCES
from killing pasta as a warning not an error.

whether