On Tue, 6 Apr 2021 at 12:58, Peter Robinson <pbrobinson@xxxxxxxxx> wrote:
On Tue, Apr 6, 2021 at 11:36 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Tue, Apr 6, 2021 at 3:23 AM Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote:
> >
> >
> >
> > On Mon, 5 Apr 2021 at 20:30, Daniel Walsh <dwalsh@xxxxxxxxxx> wrote:
> >>
> >> On 4/3/21 02:34, Tomasz Torcz wrote:
> >> > Dnia Fri, Apr 02, 2021 at 05:30:30PM -0400, Neal Gompa napisał(a):
> >> >> On Fri, Apr 2, 2021 at 5:18 PM Lars Seipel <ls@xxxxxxxx> wrote:
> >> >>> On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:
> >> >>>> Unless OpenShift and RKE recently changed so that containers can run
> >> >>>> as root by default (as of yesterday, they didn't), this is solidly a
> >> >>>> bad idea, since it makes it much more unintuitive to set up secure
> >> >>>> containers conforming with the guidelines for these Kubernetes
> >> >>>> platforms.
> >> >>> In my experience, containers trying to run stuff from shadow-utils in
> >> >>> their entrypoint/startup scripts tend to be a reason for containers to
> >> >>> *not* run on OpenShift/OKD without additional adjustments.
> >> >>>
> >> >>> A related (and more common) issue are images that expect to run with a
> >> >>> particular named user (or UID) determined during the build process
> >> >>> (again, most likely created using shadow-utils).
> >> >>>
> >> >>> I'm not familiar with Rancher but at least for OpenShift, I don't think
> >> >>> the availability of shadow-utils is very useful. At run time, you can't
> >> >>> use the shadow-utils at all and whatever you do with it during build
> >> >>> time is unlikely to be helpful (and actively harmful more often than
> >> >>> not) at run time when OpenShift assigns you an arbitrary UID.
> >> >> It's basically required for building containers that will work at
> >> >> runtime where OpenShift assigns an arbitrary UID.
> >> >>
> >> >> For example, in my containers, I *build* and create a "runtime user"
> >> >> with the UID 1000, and then set things up to use that context at the
> >> >> end. OpenShift uses that for its dynamic UID assignment.
> >> > But you do not need shadow-utils for that. Even OpenShift
> >> > documentation shows simple echo is enough:
> >> >
> >> > if ! whoami &> /dev/null; then
> >> > if [ -w /etc/passwd ]; then
> >> > echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
> >> > fi
> >> > fi
> >> > https://docs.openshift.com/container-platform/3.10/creating_images/guidelines.html
> >> > (yeah, I know it's an old and obsolete version of docs)
> >> >
> >> What about all of the users of Docker and Podman who do?
> >>
> >>
> >>
> >> ```
> >>
> >> from fedora
> >>
> >> run useradd XYZ
> >>
> >> user XYZ
> >>
> >> ...
> >>
> >> ```
> >>
> >> Do you just break them out of the box?
> >
> >
> > Yes and that's the point of the Change Proposal (ie make this more widely known and allow people to change their Dockerfile). This change would only be applied starting from the Fedora 35 base image, I don't think it is unreasonable to have breaking change between major version of the container base image.
> >
>
> I think it would be unreasonable to break such a commonly established
> pattern, though. That's enough of a reason for people to stop using
> the Fedora base container.
We do have the Base container and a Base Minimal, so maybe do it in
the later and not the former?
Yes that's a good suggestion :-), I can probably make another Change for that tho.
Based on the feedback received, I will update the change proposal to exclude shadow-utils from the packages proposed to be removed. That way we should be able to move on and at least remove sssd-client and util-linux ;-)
_______________________________________________
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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure