cbl-mariner images don't include useradd
danegsta opened this issue · comments
I'm looking to use the cbl-mariner based images as part of an AzDO pipeline to build a Go client library, but AzDO pipelines run useradd
as part of initializing a custom build container. The cbl-mariner images don't include useradd
by default, so running the container fails.
I've been falling back to using the Debian based images, but would prefer using the cbl-mariner image if possible. According to microsoft/azurelinux#3239, useradd
comes from the shadow-utils
package. Would it be possible to update the build scripts for the mariner images to include shadow-utils
along with the other package dependencies that are installed currently?
On a related note, adding the sudo
package would also be helpful in order to make it easier to install other custom dependencies in the container for my build, but I have workarounds I can use if sudo
is missing, while there is currently no way to workaround useradd
not being present.
I think adding useradd
(shadow-utils
) is a good spot to improve parity, making it more possible to drop CBL-Mariner into an existing build:
$ docker run -it --rm golang:1.22.1 useradd
Usage: useradd [options] LOGIN [...]
$ docker run -it --rm mcr.microsoft.com/oss/go/microsoft/golang:1.22.1-2 useradd
Usage: useradd [options] LOGIN [...]
$ docker run -it --rm mcr.microsoft.com/oss/go/microsoft/golang:1.22.1-2-cbl-mariner2.0 useradd
[...] exec: "useradd": executable file not found in $PATH: unknown.
I'm not so sure about sudo
, at least it can't be justified in the same way:
$ docker run -it --rm golang:1.22.1 sudo
[...] exec: "sudo": executable file not found in $PATH: unknown.
$ docker run -it --rm mcr.microsoft.com/oss/go/microsoft/golang:1.22.1-2 sudo
[...] exec: "sudo": executable file not found in $PATH: unknown.
$ docker run -it --rm mcr.microsoft.com/oss/go/microsoft/golang:1.22.1-2-cbl-mariner2.0 sudo
[...] exec: "sudo": executable file not found in $PATH: unknown.
Our primary objective with these images is that you should be able to switch from upstream/official images to ours without surprises. The other way around matters too, though: if someone uses our images to build forked OSS code and make changes to the OSS code that only work with our images, they wouldn't realize it, and would have problems when they try to contribute the improvements to the OSS code upstream where the official Go images are still used.
I don't think we've formally thought out that sequence of events for our images in particular, but it's important to us when we consider making various Go compiler/toolset changes, so I think it makes sense here too. /cc @microsoft/golang-compiler
There's a fairly straightforward workaround I'm currently using to install sudo
in AzDO build containers that don't have it, so lacking sudo
isn't a blocking issue.
We just got a separate report that AzDO assumes groupadd
is installed, another util provided by this package.
The images on MAR have been updated to include this package--tested on these tags:
mcr.microsoft.com/oss/go/microsoft/golang:1.21-cbl-mariner2.0
mcr.microsoft.com/oss/go/microsoft/golang:1.21-fips-cbl-mariner2.0
mcr.microsoft.com/oss/go/microsoft/golang:1.22-cbl-mariner2.0
mcr.microsoft.com/oss/go/microsoft/golang:1.22-fips-cbl-mariner2.0
Thanks for pointing this out. 👍
I'm also adding su
for the same reasons (upstream has it and AzDO tries to use it), provided by util-linux
. Also, git
.