Re: Apparmor (and other) Issues

[Stefano Brivio <sbrivio@redhat.com>]

On Wed, 19 Feb 2025 06:31:49 +0000
Prafulla Giri <prafulla.giri@protonmail.com> wrote:

> On Monday, February 17th, 2025 at 1:22 PM, Stefano Brivio <sbrivio@redhat.com> wrote:
> 
> > You mean 'passt', and:
> >   
> Strangely enough, I did mean pasta: that's the one that gives a shell. passt only creates namespace thingy. I thought pasta used passt underneath and that is why changes to passt was visible by testing pasta. Am I doing something wrong?

They are the same binary. Simplistically: one (pasta) gives you a shell
but you can also use it with Podman (or Docker), the other one (passt)
gives you a UNIX domain socket and you can use it with QEMU (or
libkrun/muvm).

They just need to be invoked as different commands, so a symlink would
normally be enough, except that AppArmor profiles can't be (separately)
associated to symlinks, so the Debian and openSUSE packages install a
hard link (and Fedora packages a copy).

> > https://salsa.debian.org/sbrivio/passt/-/commit/5bb812e79143670a57440cd8aa7f2979583c5a0a
> > 
> > might explain it. You need to create hard links ('make install' doesn't
> > do that) to associate different AppArmor profiles.
> > 
> > In any case, I'm releasing (and packaging) a new version with the
> > AppArmor workaround today.
> >   
> I just checked on Debian Sid and I can confirm that everything is working as expected. Thank you very much for your hard work. As I understand it, a better Apparmor fix is being discussed with other maintainers in the meantime. But as things stand right now, Debian users ought to be able to use passt with libvirt, as expected.
> 
> In the meantime, I have noticed another error and want to ask where I ought to report it: If a VM isn't able to run, passt configs aren't cleared. I just had a VM not start because of permission errors (I resolved it), but trying to restart the VM threw a passt error saying the port being forwarded was already in use (a remnant of previous run that failed). I'll have to come up with a way to make this reproducible, of course. But it seems that on unclean exits, passt isn't being allowed to clean things up (destroy the created namespace, stop the port-forwards, etc.) Perhaps I ought to report this on libvirt side? I encountered this error through virt-manager. Perhaps I should test with virsh as well.

There's no persistent configuration stuff left around: if you run
stand-alone pasta, the detached namespace will go away on its own.

The sockets passt(1) creates remain until libvirt cleans them up (passt
can't do that because it remounts its root filesystem to an empty
filesystem as it starts).

Bound ports, you might need to wait up to two minutes after sockets are
closed, because they will be in TIME_WAIT state for that time. That
comes from the definition of MSL (Maixmum Segment Lifetime, RFC 9293
section 4.). The kernel wants to make sure that in-flight TCP segments
don't reach another process by mistake.

-- 
Stefano