Your message dated Mon, 17 Mar 2025 13:19:36 +0000
with message-id <[email protected]>
and subject line Bug#1100135: fixed in apparmor 4.1.0~beta5-4
has caused the Debian Bug report #1100135,
regarding Conflict between Podman Profile and Pasta profile breaks rootless
network shutdown
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1100135: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100135
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
package: apparmor
version: 4.1.0~beta5-3
severity: important
x-debbugs-cc: [email protected], [email protected],
[email protected],
[email protected]
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
--- End Message ---
--- Begin Message ---
Source: apparmor
Source-Version: 4.1.0~beta5-4
Done: intrigeri <[email protected]>
We believe that the bug you reported is fixed in the latest version of
apparmor, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
intrigeri <[email protected]> (supplier of updated apparmor package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Mon, 17 Mar 2025 11:15:38 +0000
Source: apparmor
Architecture: source
Version: 4.1.0~beta5-4
Distribution: unstable
Urgency: medium
Maintainer: Debian AppArmor Team <[email protected]>
Changed-By: intrigeri <[email protected]>
Closes: 1100007 1100135
Changes:
apparmor (4.1.0~beta5-4) unstable; urgency=medium
.
* Remove obsolete /etc/apparmor.d/zgrep conffile (Closes: #1100007)
* Don't ship the podman stub profile (Closes: #1100135)
Checksums-Sha1:
7471c22872d69b83e4dc3f32e02cdc4a1e2a17eb 3336 apparmor_4.1.0~beta5-4.dsc
d3236d653e1c03da79277652ad6703ac34629c4b 93620
apparmor_4.1.0~beta5-4.debian.tar.xz
Checksums-Sha256:
0109368a8b1943913f4c9951e9d9480ac62a17932bf2c96ada93b74e86570ec6 3336
apparmor_4.1.0~beta5-4.dsc
c4c8f971dffadb21b08e9e9b9f0d4ad8404bc5e8a8dedb374eae2c96f12c9859 93620
apparmor_4.1.0~beta5-4.debian.tar.xz
Files:
ea4d5284fa84e774bdf4144e00384b5e 3336 admin optional apparmor_4.1.0~beta5-4.dsc
a1bb6f547de3474da5ba089b55be9d18 93620 admin optional
apparmor_4.1.0~beta5-4.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iIsEARYKADMWIQRhtDRcZu/HkP7YWcafj6cvaVTDowUCZ9gcNRUcaW50cmlnZXJp
QGRlYmlhbi5vcmcACgkQn4+nL2lUw6Oh5gD/SF8hjFzSQERfv+GdHZjP6A0QvCPY
wd89r4EBbaWAawcA/R9Cq+kYaUE95TUEqFDkh+0RKo0B6tkfDREhQUUnu2cI
=EaYG
-----END PGP SIGNATURE-----
pgp4AtQwDtz_s.pgp
Description: PGP signature
--- End Message ---
