On Wed, 17 Sep 2025 19:47:05 +0800 ChangZhuo Chen (陳昌倬) <[email protected]> wrote:
> On Wed, Sep 17, 2025 at 12:49:26PM +0200, Stefano Brivio wrote: > > > [...] > > > > 4. if 3. doesn't change anything, disable AppArmor altogether > > (temporarily, just for the test!) with 'aa-teardown', and try again? > > It works after `aa-teardown`: > > $ sudo aa-teardown > Unloading AppArmor profiles > > $ pasta -- true > No interfaces with usable IPv4 routes > No interfaces with usable IPv6 routes So it's AppArmor, but I can't reproduce this with the current policy (I still have to try with a fresh re-install of the package though). > > 3. 'aa-enforce pasta', and then start it again? > > Try with normal user: > > $ aa-enforce pasta > Cannot write to profile directory. > Please run as a user with appropriate permissions. > > ERROR: Cannot write to profile directory: /etc/apparmor.d > > Try with sudo > > $ sudo aa-enforce pasta > Setting /usr/bin/pasta to enforce mode. > Warning: profile pasta represents multiple programs ...oops, sorry, I meant to ask if you could try with 'aa-complain pasta' instead of aa-enforce (also as root or with sudo, I forgot to mention). That is, now that we know it's something off with the AppArmor policy, I'm trying to understand if it's the correct profile being applied, at least. If it is, 'aa-complain pasta' would also make things work. We had some related glitches in the past, solved here: https://salsa.debian.org/sbrivio/passt/-/commit/5bb812e79143670a57440cd8aa7f2979583c5a0a https://salsa.debian.org/sbrivio/passt/-/commit/b52557fedcb1772ed47b05c095d81f7aac9657d9 https://salsa.debian.org/sbrivio/passt/-/commit/4a77ef55c34c579d4845aa2dfd003abf2195ea9b -- Stefano
