[PATCH] apparmor: Fix signaling issues from podman

[PATCH] apparmor: Fix signaling issues from podman

[Bittner, Jan]

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

This fixes a bug that causes a crash in podman. Podman uses signal to
communicate with pasta. Without this patch apparmor does not allow
podman to signal pasta and kills pasta instead. Killing pasta causes
podman to crash. You can reproduce this by starting a rootless podman
socket and starting a container via the socket using podman remote or
docker.
Links: https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2154379

Signed-off-by: Jan Philipp Bittner <jan.bittner@kdo.de>
---
 contrib/apparmor/usr.bin.pasta | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/apparmor/usr.bin.pasta b/contrib/apparmor/usr.bin.pasta
index 56b5024..b0838de 100644
--- a/contrib/apparmor/usr.bin.pasta
+++ b/contrib/apparmor/usr.bin.pasta
@@ -18,6 +18,9 @@ include <tunables/global>
 profile pasta /usr/bin/pasta{,.avx2} flags=(attach_disconnected) {
   include <abstractions/pasta>

+  # Allow podman to signal pasta
+  signal (receive) peer=podman,
+
   # Alternatively: include <abstractions/user-tmp>
   /tmp/**                              rw,     # tap_sock_unix_open(),
                                                # tap_sock_unix_init(), pcap(),
--
2.43.0

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 9516 bytes --]

Re: [PATCH] apparmor: Fix signaling issues from podman

[Stefano Brivio]

Jan,

On Thu, 28 May 2026 14:08:40 +0000
"Bittner, Jan" <Jan.Bittner@kdo.de> wrote:

> This fixes a bug that causes a crash in podman. Podman uses signal to
> communicate with pasta. Without this patch apparmor does not allow
> podman to signal pasta and kills pasta instead. Killing pasta causes
> podman to crash. You can reproduce this by starting a rootless podman
> socket and starting a container via the socket using podman remote or
> docker.
> Links: https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2154379
> 
> Signed-off-by: Jan Philipp Bittner <jan.bittner@kdo.de>
> ---
>  contrib/apparmor/usr.bin.pasta | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/contrib/apparmor/usr.bin.pasta b/contrib/apparmor/usr.bin.pasta
> index 56b5024..b0838de 100644
> --- a/contrib/apparmor/usr.bin.pasta
> +++ b/contrib/apparmor/usr.bin.pasta
> @@ -18,6 +18,9 @@ include <tunables/global>
>  profile pasta /usr/bin/pasta{,.avx2} flags=(attach_disconnected) {
>    include <abstractions/pasta>
> 
> +  # Allow podman to signal pasta
> +  signal (receive) peer=podman,

Thanks a lot for investigating this and for the patch.

As we discussed on IRC: a similar issue was reported on Debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100135

and there it was "solved" by dropping the stub profile for Podman,
which doesn't seem to be an option for Ubuntu (I'm not sure why):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100135#12

but, on the other hand, as I was arguing at:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100135#17

according to what seem to be common AppArmor practices, this rule
shouldn't be part of pasta's own profile, rather be in Podman's
profile, which would then include pasta's "abstraction".

That way, pasta would be granted the ability to receive signals from
Podman when started from Podman, but not otherwise. That is, pasta's
abstraction is designed to be the minimum set of rules for all users,
including stand-alone usage or others.

In this case, though, the difference in permissions is minimal, and we
already have plenty of workarounds in place for libvirt's policies, so
it wouldn't really be that bad.

If having this upstream actually helps fixing the issue for Ubuntu
users and it's much more convenient than the alternative, then I think
it should be merged.

But if a proper Podman profile, or at least a starting point, see also:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100135#31

is something that could be introduced relatively soon, then maybe we
should go that way.

And, if not, if shipping a downstream patch in Ubuntu would take a
similar time and effort, I'd rather suggest to go that way, so that we
avoid introducing a slightly wrong rule for others (e.g. Debian).

If it's not the case, though, let me know.

By the way, Paul supplied a minimal reproducer:

  podman unshare --rootless-netns true

-- 
Stefano