Re: [PATCH] CI: Switch the alpine containers to be non-root

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 10 Sep 2025, Andrew Cooper wrote:
> On 10/09/2025 12:57 pm, Marek Marczykowski-Górecki wrote:
> > On Wed, Sep 10, 2025 at 12:34:16PM +0100, Andrew Cooper wrote:
> >> Testing on staging-4.19 is hitting a reliable failure, caused by 
> >> alpine/3.18
> >> being a root build container, but debian/12-x86_64 being a non-root test
> >> container.  Specifically, the test container can't copy XEN_PAGING_DIR and
> >> XEN_DUMP_DIR (both 700) from the build root in order to construct the 
> >> initrd.
> >>
> >> staging-4.20 and later do not repack the initrd in this way, so are not
> >> affected.
> >>
> >> Switch both alpine containers to being non-root.  This is still slightly
> >> fragile, but better than depending on using root containers for both.
> > This will likely explode done as is...
> >
> > First, grub.cfg is not writable anymore:
> > https://gitlab.com/xen-project/hardware/xen-staging/-/jobs/11305545275#L170
> >
> > I'm not sure what 'user' gets remapped to here, but the whole container
> > is running under rootless podman, as gitlab-runner user. Files on the
> > host are owned by gitlab-runner user.
> >
> > But second, repacking initrd as non-root, without any extra care will
> > result in broken initrd. At the very least /sbin/mount is suid root -
> > when repacked as normal user, it will end up as suid to non-root,
> > breaking it quite effectively. I've run into this issue when needing to
> > repack rootfs anyway and ended up using fakeroot (again):
> > https://gitlab.com/xen-project/people/marmarek/xen/-/commit/bab939159127a9f8e56e119c1fa553c7bbb6d4f7
> >
> > At least your "CI: Create initrd fragments explicitly as root" patch may
> > need backporting, but TBH I'm not sure if that's enough. /dev will
> > likely be messed up too.
> 
> There's a lot of collateral damage here.  Summarising things a little.
> 
> * We cannot change the root-ness of alpine/3.18-arm64v8.  Like
> xilinx-xenial, it does need root to drive real hardware

Apologies for joining this thread late. I wanted to add that it is
OK to separate containers intended to drive real hardware, such
as xenial-xilinx, from regular build containers. For example,
3.18-arm64v8 could be moved out and used only in .adl-x86-64,
similar to how xenial-xilinx is used only in .xilinx-arm64.
Normal build jobs, such as alpine-3.18-gcc-arm64, could use a
different container.

I suggest we rename 3.18-arm64v8 to something else and create a new
3.18-arm64v8 specifically for builds, to be used only in build jobs.

The renamed original 3.18-arm64v8, together with xenial-xilinx, could be
moved under test-artifacts/ or another appropriate location, as they do
not quite belong with the other build containers. This separation also
aligns with the root/non-root distinction.