BASH_ENV trick should perhaps setup libnss_wrapper as well. about s2i-python-container HOT 7 CLOSED

I'm guessing this issue should be opened against https://github.com/sclorg/s2i-base-container rather than the python image. But has my full support!

from s2i-python-container.

One thing you may have to be careful of in doing this is that you may want to skip setting up libnss_wrapper if the user ID is the default 1001 user. There would strictly be no need to do it in that case.

Not that situation would arise under OpenShift, but `libnss_wrappershould never be setup when the user ID is0``. It will not work in that situation.

This would only ever arise if for some reason someone took an image generated by S2I and used it with normal Docker service and forced it to run as root by using docker run -u option.

from s2i-python-container.

we've actually started to move away from libnss wrapper and instead are just chmod'ing /etc/passwd to make it group-writable and then updating it during startup:

https://github.com/openshift/jenkins/blob/master/2/Dockerfile#L53
https://github.com/openshift/jenkins/blob/master/2/contrib/s2i/run#L59-L61
https://github.com/openshift/jenkins/blob/master/2/contrib/jenkins/jenkins-common.sh#L12-L22

it's a much simpler approach and should address the issue described here. I would recommend the SCL images adopt it.

from s2i-python-container.

@hhorak see my last comment.

from s2i-python-container.

@bparees Does that approach have any drawbacks over libnss wrapper?

Also, I agree with @soltysh, this should be opened against s2i-base. If there's no opposition, I'll do it later today.

from s2i-python-container.

@bparees Does that approach have any drawbacks over libnss wrapper?

it makes people nervous because /etc/passwd is writable by anyone. but we haven't actually found a way to exploit that fact, so assuming someone doesn't come up with something, i don't think there are any drawbacks... from a functional perspective it's certainly much nicer/simpler.

from s2i-python-container.

Let's track this issue only in sclorg/s2i-base-container#116.

from s2i-python-container.