odo: odo component fails when anyuid is set

UPDATE 2019-04-17

see https://github.com/openshift/odo/issues/1623#issuecomment-484110785

Original issue description

I’m unable to create component due to failure in one of the iniContainer (copy-files-to-volume)

~~The strange part is that this is not consistent it is happening only sometimes.~~ Update: Now I’m getting this every time on OpenShift 4.0 cluster

▶ odo push
 ✓  Checking component
 ✓  Checking component version
 ✓  Creating java component with name java-bayi
 ✓  Initializing 'java-bayi' component
 ✓  Creating component java-bayi
 ✓  Successfully created component java-bayi
 ✓  Applying component settings to component: java-bayi
 ✓  Checking URL java-bayi-8080
 ✓  Successfully created URL for component: java-bayi
 ✓  http://java-bayi-8080-spring-boot-kvcm-default.apps.tkral.devcluster.openshift.com
 ✓  The component java-bayi was updated successfully
 ✓  Successfully updated component with name: java-bayi
 ✓  Pushing changes to component: java-bayi of type binary
 ✗  Waiting for component to start
 ✗  waited 4m0s but couldn't find running pod matching selector: 'deploymentconfig=java-bayi-spring-boot-kvcm'


▶ oc get pods
NAME                                  READY   STATUS                  RESTARTS   AGE
java-bayi-spring-boot-kvcm-1-cz86r    0/1     Init:CrashLoopBackOff   4          2m34s
java-bayi-spring-boot-kvcm-1-deploy   1/1     Running                 0          2m44s


▶ oc logs java-bayi-spring-boot-kvcm-1-cz86r -c copy-files-to-volume
mkdir: cannot create directory '/mnt/app-root.setup-volume': Permission denied
tar: /opt/app-root: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
mv: cannot stat '/mnt/app-root.setup-volume': No such file or directory

I’m able to observe this only on OpenShift 4.0. Haven’t noticed this error last week 😦

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 22 (18 by maintainers)

Commits related to this issue

Adds security context / SYS_ADMIN privileges to bootstrap container There are multiple issues in getting volume support / PVC to work inside of an OpenShift container, such as: https://bugzilla.redha... — committed to cdrage/odo by cdrage 5 years ago

Most upvoted comments

It is NOT related to the OpenShift cluster version. It IS related to anyuid security context`.

Fails if OpenShift user is allowed to run containers in `anyuid` security context.

Java S2I image (registry.access.redhat.com/redhat-openjdk-18/openjdk18-openshift) uses jboss as a user inside the container.

When container is allowed to run in anyuid security context the user will be jboss.

$ id
uid=185(jboss) gid=0(root) groups=0(root),185(jboss)

Probelm is that that OpenShift mounts the volume with root:root as owner. jboss user can’t write to the directory.

$ touch /mnt/asdf
touch: cannot touch '/mnt/asdf': Permission denied

$ ls -lha /mnt/
total 20K
drwxr-xr-x. 3 root root 4.0K Apr 17 13:17 .
drwxr-xr-x. 1 root root    6 Apr 17 13:20 ..
drwx------. 2 root root  16K Apr 17 13:01 lost+found

If the java s2i image used root this would work

Everything is OK if OpenShift user is not allowed to run in `anyuid` security context

Even though S2I image uses jboss user, OpenShift will execute the container with random uid.

$ id
uid=1000470000 gid=0(root) groups=0(root),1000470000

In this case the volume is mounted with the the same group as the assigned user. So there is no problem with accesssing the volume.

$ ls -lah /mnt/
total 20K
drwxrwsr-x. 3 root 1000470000 4.0K Apr 17 14:09 .
drwxr-xr-x. 1 root root          6 Apr 17 14:09 ..
drwxrwS---. 2 root 1000470000  16K Apr 17 14:09 lost+found

$ touch  /mnt/asdf

$ ls -lah /mnt/
total 20K
drwxrwsr-x. 3 root       1000470000 4.0K Apr 17 14:20 .
drwxr-xr-x. 1 root       root          6 Apr 17 14:09 ..
-rw-r--r--. 1 1000470000 1000470000    0 Apr 17 14:20 asdf
drwxrwS---. 2 root       1000470000  16K Apr 17 14:09 lost+found

Setting or not setting anyuid is not in our control

kadel on Apr 17, 2019