Re: systemd-sysusers versus containers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 17, 2019 at 10:34 AM Daniel Walsh <dwalsh@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux