Description of problem: When using the image source input mechanism, the directories that are injected are created with 0700 permissions which makes them inaccessible to the random container uid at runtime. Many of the openshift images run a "fix-permissions" script as part of the assemble script, which updates the permissions and masks this problem, but any s2i builder image which does not run fix-permissions, or any docker build, will see the files with overly strict permissions. How reproducible: always Steps to Reproduce: 1. define a build that uses image source input 2. select for input a nested directory structure from the input/source image 3. check the permissions of the directories injected into the final application image Actual results: directory permissions are 0700 and the directory is owned by the default user for the builder/base image. Expected results: directory permissions are 755 or 750 and belong to the root group so the randomly assigned container uid can access them. This is a regression from 3.5, so you can also compare with the behavior of 3.5 Additional info:
Fix to s2i (needs to be vendored into origin): https://github.com/openshift/source-to-image/pull/787
Hi, ben I try to reproduce this bug like below steps: 1.Create bc using image source input # oc new-build openshift/ruby:latest https://github.com/openshift/ruby-hello-world --source-image=openshift/jenkins:latest --source-image-path=/opt/openshift:xiuwangtest/subdir/ --name=final-app 2.Then find built image on node # docker run -it docker-registry.default.svc:5000/dyan1/final-app /bin/bash bash-4.2$ ls -al drwxrwxr-x. 3 default root 20 Aug 9 10:15 xiuwangtest bash-4.2$ ls -al xiuwangtest/ total 4 drwxrwxr-x. 3 default root 20 Aug 9 10:15 . drwxrwxr-x. 12 default root 4096 Aug 9 10:15 .. drwxrwxr-x. 3 default root 23 Aug 9 10:15 subdir bash-4.2$ ls -al xiuwangtest/subdir/ total 0 drwxrwxr-x. 3 default root 23 Aug 9 10:15 . drwxrwxr-x. 3 default root 20 Aug 9 10:15 .. drwxrwx---. 4 default root 70 Aug 9 10:15 openshift cannot reproduce, could you please help check my steps, is it correct additional info: openshift v3.6.173.0.5 kubernetes v1.6.1+5115d708d7 etcd 3.2.1 # oc get all NAME TYPE FROM LATEST bc/final-app Source Git 2
the assemble script in the ruby image includes a "fix-permissions" step which updates all the permissions and masks this problem. you need to run your build with an assemble script that does not invoke fix-permissions at the end.
this is what i'm referring to: https://github.com/sclorg/s2i-ruby-container/blob/master/2.4/s2i/bin/assemble#L62
Thanks, ben I can reproduce it # docker run -it docker-registry.default.svc:5000/dyan1/final-app /bin/bash bash-4.2$ ls -l drwxr-xr-x. 3 default root 20 Aug 10 04:19 xiuwangtest bash-4.2$ ls -l xiuwangtest/ total 0 drwxr-xr-x. 3 default root 23 Aug 10 04:19 subdir bash-4.2$ ls -l xiuwangtest/subdir/ total 0 drwx------. 4 default root 70 Aug 10 04:19 openshift bash-4.2$ ls -l xiuwangtest/subdir/openshift/ total 8 drwx------. 4 default root 128 Aug 10 04:19 configuration -rwxr-xr-x. 1 default root 2153 Aug 10 04:19 password-encoder.jar drwx------. 2 default root 4096 Aug 10 04:19 plugins
Test with docker build and sti build cannot reproduce this bug # docker run -it docker-registry.default.svc:5000/dyan-test/final-app /bin/bash bash-4.2$ ls -l drwxr-xr-x. 3 default root 20 Aug 23 02:35 xiuwangtest bash-4.2$ ls -l xiuwangtest/ total 0 drwxr-xr-x. 3 default root 23 Aug 23 02:35 subdir bash-4.2$ ls -l xiuwangtest/subdir/ total 0 drwxr-xr-x. 4 default root 70 Aug 23 02:35 openshift bash-4.2$ ls -l xiuwangtest/subdir/openshift/ total 12 drwxr-xr-x. 4 default root 151 Aug 23 02:35 configuration -rwxr-xr-x. 1 default root 2153 Aug 23 02:35 password-encoder.jar drwxr-xr-x. 2 default root 4096 Aug 23 02:35 plugins openshift v3.6.173.0.7 kubernetes v1.6.1+5115d708d7 etcd 3.2.1
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2642