package: apparmor
version: 4.1.0~beta5-3
severity: important
x-debbugs-cc: pod...@packages.debian.org, pa...@packages.debian.org,
golang-github-containers-com...@packages.debian.org,
tim.mil...@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
