MIME-Version: 1.0
References: <CA+gy4ieuXLuQddxmPuiucyZbut=14cR8tgmGrh0qE9qLDBivmg@mail.gmail.com>
 <20210505091919.5257051e@vostro>
In-Reply-To: <20210505091919.5257051e@vostro>
From: Konstantin Kulikov <k.kulikov2@gmail.com>
Date: Wed, 5 May 2021 10:17:56 +0300
Message-ID: <CAD+eXGQ9BvZSD2UJqdfVxHw1g42Yc3hzkKB-xfD3TAOkdexbQg@mail.gmail.com>
Subject: Re: Containerised APK builds and security xattrs
To: Timo Teras <timo.teras@iki.fi>
Cc: Ross Younger <crazyscot@gmail.com>, ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

Some packages also use libcap to enable servers to listen on port 80
without root privs.

On Wed, May 5, 2021 at 9:20 AM Timo Teras <timo.teras@iki.fi> wrote:
>
> Hi,
>
> There are multiple reasons why we want the xattrs. Originally it was
> introduced to store the grsec kernel pax flags, and some packages also
> use it to set capabilities for some executables. APK also internally
> uses XATTRs for the file hash, but that happens transparently and never
> hits the disk surface.
>
> It might make sense an abuild option to not include the on-disk xattrs,
> or be able to filter them. Currently, you could perhaps just strip the
> xattrs manually in APKBUILD build() or package() stage?
>
> Timo
>
> On Wed, 5 May 2021 17:05:57 +1200
> Ross Younger <crazyscot@gmail.com> wrote:
>
> > I am building my own APKs for local use, targeting alpine 3.13.
> >
> > It seems that abuild causes package contents to inherit security
> > xattrs from the host OS (if present). This is tripping me up as these
> > packages fail to install on a container hosted by an OS that doesn't
> > have security contexts enabled.
> >
> > I use Bitbucket for source control and am trying to set up
> > containerised CI in Bitbucket pipelines.
> > When I build my container using Bitbucket Pipelines the APK is
> > different from when I build locally!
> >
> > When built on-cloud, the files in the APK contain security.selinux
> > xattrs. When built locally, they don't. (I have a script that runs the
> > Bitbucket pipeline in a local container, so I'm pretty sure the same
> > build steps are being followed.)
> >
> > Installing an APK built on the cloud to a container on my local
> > machine fails:
> >
> >     /here # apk add --allow-untrusted date_h-dev-3.0.0-r2.apk
> >     (1/1) Installing date_h-dev (3.0.0-r2)
> >     ERROR: Failed to set xattrs on
> > usr/include/date/.apk.13d8a17d6f42822d457261eae2fa9ea9ba43faf2c673bf68:
> > Operation not permitted
> >     [...]
> >     1 error; 211 MiB in 53 packages
> >
> > I have dug far enough to find that abuild explicitly calls `tar
> > --xattrs ...' when creating the package, and that `apk add' is simply
> > attempting to preserve that.
> >
> > Is there any chance that that `tar --xattrs' in abuild might one day
> > change to --no-xattrs, or to something more complex that filters out
> > selinux xattrs? Perhaps you have a good reason for explicitly
> > including xattrs.
> >
> > Or am I better off using something other than Bitbucket? Are there any
> > CI services you recommend (or disrecommend) for building APKs?
> >
> > Thanks for your attention.
> >
> > Ross
>