systemd-sysusers versus containers

[Troy Dawson]

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]

Any ideas on what we recommend to users?

Troy Dawson

[1] - https://pagure.io/packaging-committee/issue/442
[2] - The amount a container grows when systemd is added depends on
how many of the systemd dependencies are needed by the main container
packages. As of F31, if they need none of these dependency packages,
then a container grows by 60M by adding systemd.
[3] - https://pagure.io/minimization/issue/13

[Lennart Poettering]

On Mo, 16.09.19 09:45, Troy Dawson (tdawson(a)redhat.com) 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]
>
>  Any ideas on what we recommend to users? 
systemd-tmpfiles runs without PID 1 being systemd. That said,
something needs to run it. Typically that's a service manager of some
kind, since the tool is wrapped as a service. If you don't have that,
you need to call it yourself somehow differently...

That all said it's entirely sufficient to invoke the tool at container
build time, and RPM scriptlets generally do that anyway. In that case
there's no need to have it around at runtime.

Lennart

--
Lennart Poettering, Berlin

[John M. Harris, Jr.]

Why exactly is systemd-sysusers needed here anyway? Do you not have a passwd and shadow
file?

On September 16, 2019 5:41:04 PM UTC, Lennart Poettering <mzerqung(a)0pointer.de&gt;
wrote:
> On Mo, 16.09.19 09:45, Troy Dawson (tdawson(a)redhat.com) 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]
> >
> > Any ideas on what we recommend to users?
>
> systemd-tmpfiles runs without PID 1 being systemd. That said,
> something needs to run it. Typically that's a service manager of some
> kind, since the tool is wrapped as a service. If you don't have that,
> you need to call it yourself somehow differently...
>
> That all said it's entirely sufficient to invoke the tool at container
> build time, and RPM scriptlets generally do that anyway. In that case
> there's no need to have it around at runtime.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Sep 16, 2019 at 06:45:09PM +0000, John M. Harris, Jr. wrote:
>  Why exactly is systemd-sysusers needed here anyway? Do you not have a
> passwd and shadow file? 
systemd-sysusers is a tool to add entries to /etc/passwd and /etc/shadow.
It does a similar job to useradd and groupadd.

Zbyszek

[Colin Walters]

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...

[Daniel Walsh]

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/additiona...
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]

[Troy Dawson]

On Tue, Sep 17, 2019 at 10:34 AM Daniel Walsh <dwalsh(a)redhat.com&gt; 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/additiona...
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

[John M. Harris Jr.]

On Monday, September 16, 2019 11:49:52 AM MST Zbigniew Jędrzejewski-Szmek 
wrote:
>  On Mon, Sep 16, 2019 at 06:45:09PM +0000, John M. Harris, Jr. wrote:
>  
>  > Why exactly is systemd-sysusers needed here anyway? Do you not have a
>  > passwd and shadow file?
>  
>  systemd-sysusers is a tool to add entries to /etc/passwd and /etc/shadow.
>  It does a similar job to useradd and groupadd.
>  
>  Zbyszek 
In that case, it sounds like this could be avoided by simply using the 
traditional tools.. That way you wouldn't need to pull in systemd.