On Tue, Sep 17, 2019 at 10:34 AM Daniel Walsh <dwa...@redhat.com> wrote: > > On 9/17/19 8:04 AM, Colin Walters wrote: > > > > 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) > Podman and CRI-O handle this now, by adding the runasuser to the > /etc/passwd inside of the container, if it does not exists. > > > > 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/additional_concepts/authorization.html#security-context-constraints
One of the comments in the ticket was to try pulling out systemd-sysusers into it's own sub-package. systemd-sysusers requires libsystemd-shared Pulling libsystemd-shared into it's own sub-package shows that it requires cryptsetup-libs which sets up a circular dependency back to systemd. After many attempts, just using rpm packaging techniques, I have been unsuccessful in breaking the circular dependency. The only way I can see to do it is either remove some functionality, or do some type of re-writting of code in systemd and/or one of the packages in the circular dependency. The "systemd-container-stub" is looking more and more like the way to go. Troy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
