Bug 1479130 - Directory permissions are incorrect when using Image Source input
Directory permissions are incorrect when using Image Source input
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Build (Show other bugs)
3.6.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.6.z
Assigned To: Ben Parees
Wenjing Zheng
: Regression
Depends On:
Blocks: 1480312
  Show dependency treegraph
 
Reported: 2017-08-07 23:50 EDT by Ben Parees
Modified: 2017-09-07 23:15 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Permissions on directories injected as a build input via the image source input mechanism have user-only access permissions. Consequence: The resulting application image cannot access the content when run as a random user id. Fix: The directories will be injected with group permissions which will allow the container user to access the directories. Result: The directories will be accessible at runtime as desired.
Story Points: ---
Clone Of:
: 1480312 (view as bug list)
Environment:
Last Closed: 2017-09-07 23:15:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker CLOUD-1982 Blocker Verified Custom extensions are broken with OCP3.6 2017-10-18 10:13 EDT

  None (edit)
Description Ben Parees 2017-08-07 23:50:25 EDT
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:
Comment 1 Ben Parees 2017-08-07 23:51:06 EDT
Fix to s2i (needs to be vendored into origin):
https://github.com/openshift/source-to-image/pull/787
Comment 2 Dongbo Yan 2017-08-09 22:27:27 EDT
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
Comment 3 Ben Parees 2017-08-09 22:44:52 EDT
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.
Comment 4 Ben Parees 2017-08-09 22:45:23 EDT
this is what i'm referring to:
https://github.com/sclorg/s2i-ruby-container/blob/master/2.4/s2i/bin/assemble#L62
Comment 5 Dongbo Yan 2017-08-10 00:23:03 EDT
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
Comment 7 Dongbo Yan 2017-08-22 22:39:43 EDT
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
Comment 9 errata-xmlrpc 2017-09-07 23:15:23 EDT
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

Note You need to log in before you can comment on or make changes to this bug.