Bug: stacker errors on Ubuntu 24: parent read(): No error information

[andaaron]

stacker version

v1.0.0

Describe the bug

Hi,

Not sure if this is already tracked, but the released stacker binaries don't seem to work with Ubuntu 24:
https://github.com/project-stacker/stacker/releases/download/v1.0.0/stacker
https://github.com/project-stacker/stacker/releases/download/v0.40.5/stacker

Our tests using stacker have started failing after the runner was updated to Ubuntu 24.
This applies to both stacker v0.40.5 and the latest v1.0.0 (I tried upgrading stacker to see if a newer version works better).
Both of these versions were downloaded from https://github.com/project-stacker/stacker/releases release artifacts.
On Ubuntu 22 we are using v0.40.5 successfully.

Here is 1 example: https://github.com/project-zot/zot/blob/main/test/blackbox/annotations.bats#L108
The run where it failed: https://github.com/project-zot/zot/actions/runs/12817300695/job/35740195668

# Last output:
# entering private mount namespace failed: Permission denied
# parent read(): No error information
# error: exit status 1

Here is a 2nd example: https://github.com/project-zot/zot/actions/runs/12821167569/job/35751949840

To reproduce

1. Configuration: Ubuntu 24 + stacker v0.40.5 or v1.0.0
2. Client tool used
3. Seen error:

# entering private mount namespace failed: Permission denied
# parent read(): No error information
# error: exit status 1

Expected behavior

Here is the job from the 1st example running successfully on Ubuntu 22: https://github.com/project-zot/zot/actions/runs/12762394205/job/35570847538

Screenshots

No response

Additional context

No response

[raharper]

This is related to 24.04 change in user-namespace restrictions via AppArmor:

https://discourse.ubuntu.com/t/ubuntu-24-04-lts-noble-numbat-release-notes/39890#p-99950-security-improvements

I do think we should see about uploading stacker's AppArmor profile to work without using sysctl tunables;

The short term hammer is use of the suggested sysctls; I've also had to widen those to

kernel.apparmor_restrict_unprivileged_unconfined = 0
kernel.apparmor_restrict_unprivileged_userns = 0
kernel.apparmor_restrict_unprivileged_userns_complain = 0
kernel.apparmor_restrict_unprivileged_userns_force = 0
kernel.unprivileged_userns_apparmor_policy = 0
kernel.unprivileged_userns_clone = 1
kernel.userns_restrict = 0

[raharper]

Here's what's used when we build stacker on noble (which includes running tests as unpriv user)

dbfe650#diff-5681ba4928be666c9452a0c1a0cdcfeac0d71ad163a0804ff36a86e858de0e8eR95

[mikemccracken]

@raharper I just looked quickly at the apparmor profile suggested to allow unprivileged userns, and it looks like AA profiles assume that they will know the full path to the binary - stacker has always just run from anywhere, do you know if there's a different way to specify a binary?

If it has to be path specific, maybe we need to add a 'stacker setup' command that writes the profile and has to run before the first build?