Why is shadow-utils (providing useradd and groupadd) not included by default in core:2.0 images?

[dagood]

We've gotten two reports (one about useradd, one about groupadd) where Azure Pipelines expects them to be installed:

• cbl-mariner images don't include useradd go#1164

We produce Go images based on mcr.microsoft.com/cbl-mariner/base/core:2.0, so we're somewhat dependent on what Azure Linux 2.0 provides by default. We can add more packages in our Dockerfiles, but we're curious about this in particular because it seems to break the use of "ordinary" Azure Linux/Mariner 2.0 images in Azure Pipelines container jobs.

By contrast, current Debian and Fedora images do include useradd and groupadd by default. (We also build Debian-based Go images, but some of our users do need to use Azure Linux.)

I'm curious what the reason is for not including these tools by default, and if AzDO's (and/or Microsoft 1ES PT's?) dependency on these tools has been considered.

• Related: useradd command not found in CBL Mariner 2.0 despite existing in 1.0 #3239

/cc @gdams

[zcobol]

IMO: keeps the core container at minimum size. shadow-utils is dependent of several other packages. When installed it adds about 16M to the image. If you deploy many core images and don't need to manage user it adds a lot of wasteful storage.

[dagood]

For what it's worth, I believe that (and in principle it makes sense), but I'm curious if the Azure Pipelines dependency is intentionally not being satisfied. Or maybe AzDO's requirements for using a container in a pipeline have crept upwards over time and this hasn't been considered? There could also be a bit-more-than-core image we should be using instead that I haven't noticed.

About Azure Pipeline dependencies: after adding shadow-utils to our image, Azure Pipelines now says it also needs su (provided by util-linux and not installed by default).

[dagood]

Maybe a more straightforward question is: what image should I use in order to use Azure Linux, but with a set of dependencies similar to a buildpack-deps image?

It doesn't make sense to me for every team building dev/build images on top of Azure Linux to reinvent one.

Deployment vs. build is probably an important distinction. Size matters a lot less for build: the maintenance cost of putting together your own image can be extreme when you're in a constrained environment (large overhead to set up infra that can produce custom image builds).