rhsyseng/container-rhel-examples

container-rhel-examples's Issues

should $HOME equal $APP_ROOT

test w/ arb-uid template... maybe replace APP_ROOT w/ HOME?

Using nsswrapper is not now recommended method.

Using nsswrapper is no longer the recommended method. The preferred suggestion now is to make /etc/passwd and /etc/group writable and add entries from the ENTRYPOINT script.

See section 'Support Arbitrary User IDs`` in:

• https://docs.openshift.org/latest/creating_images/guidelines.html#openshift-specific-guidelines

For an actual example, which also includes updating /etc/group which sometimes is also necessary but docs don't mention, see:

• https://github.com/jupyter/docker-stacks/blob/master/base-notebook/start.sh#L92

update ose 3.5 repo references to 3.6

add CentOS registry links to image readme's

https://github.com/CentOS/container-index/blob/master/index.d/container-examples.yml
e.g.
$ docker pull registry.centos.org/container-examples/starter-arbitrary-uid

starter-apb stale

@jcpowermac do we update it? or remove and point folks at apb-examples if Q's arise? idk, might be nice to have a starter image that's more of a template... but its just changing so rapidly.

error for OpenShift deployments

container_linux.go:247: starting container process caused "exec: \"uid_entrypoint\": executable file not found in $PATH"

remove help file references... no longer necessary for certification

write code to simplify starter-arbitrary-uid?

starter-arbitrary-uid build/run

reference putpwent function from uid hook work?
https://github.com/tchughesiv/oci-uid-hook/blob/master/src/uidhook.c#L319

Making /etc/passwd group writable allows privilege escalation

This repository recommends making /etc/passwd group writable so that the uid_entrypoint script can add a user. At the very least, the uid_entrypoint script should end by removing the group write bit on the file, otherwise it could be written again to allow privilege escalation with su.

However, creating an image with a writeable /etc/passwd and relying on the entrypoint script to secure it means that any user who overrides the entrypoint in a container would lose that protection. Users do not generally expect that overriding an entrypoint will leave their container less secure. Therefore, while I believe this would be an improvement over the status quo, it is still flawed.

In general I am concerned that running as GID 0 may create similar unexpected vulnerabilities in cases where authors of other files on the system may have left them group-writable under GID 0 while not expecting a non-root user to be running with GID 0.