On Mon, Sep 16, 2019, at 12:45 PM, Troy Dawson wrote:
systemd-sysusers seeks to unify user creation[1]. It also has the
benefit of being able to create users on bootup. But, it pulls in the
entire systemd infrastructure with all it's dependencies.
containers do not need systemd to run. They are trying to be as small
as possible. But if a package in container needs to add a user, then
systemd is pulled in and that container grows by up to 60M.[2]
Minimizing containers, both in the short term and long term, are
important to the minimization team. We have opened an issue for
this.[3]
As I said in the big thread, what we should aim to minimize is containers built via
multi-stage build; nothing else is going to be small.
The user ID is a very interesting topic...bigger picture for example, OpenShift defaults
to the `MustRunAsRange` SCC[1] - ensuring a uid is dynamically allocated for the
container. So the `useradd` and `sysusers` stuff isn't relevant.
(We have a longstanding issue though that the uid isn't in the passwd database but I
think podman is growing some code to fix that)
For non-Kubernetes systems (e.g. installing RPMs on a host) - I think in a lot of cases,
using systemd dynamic users is best:
http://0pointer.net/blog/dynamic-users-with-systemd.html
Where possible - using it for e.g. postgres would probably be somewhat of a surprise for
admins.
It'd be useful in this discussion to look at particular containers - I'm guessing
it's things like nginx and postgres where we want to ship both an RPM and a container
image? And where things intersect here is whether or not the RPM depends on systemd.
Maybe the least bad thing is to introduce a `systemd-container-stub` package that is empty
except for Provides? Dunno...it's messy.
A whole lot of service software is container-only - it doesn't make sense to make RPMs
for them, which sidesteps a lot of this.
[1]
https://docs.openshift.com/container-platform/3.11/architecture/additiona...