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

_______________________________________________
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

Reply via email to