/app not readable when running on Openshift

[qvistgaard]

/app folder permissions is set to 0700 on docker version 1.13.1 on Redhat Enterprice 7.5:

/ # ls -al / | grep app
drw-------    1 root     root          4096 Jul 10 07:49 app

Expected behavior:
/app folder permissions should be 0755, as it is with docker version 18.03.1-ce

/ # ls -al / | grep app
drwxr-xr-x    1 root     root          4096 Jul 10 07:49 app

Steps to reproduce:
Build using configuration pasted below

Environment:
Server:
Version: 1.13.1
API version: 1.26 (minimum version 1.12)
Package version: docker-1.13.1-63.git94f4240.el7.x86_64
Go version: go1.9.2
Git commit: 94f4240/1.13.1
Built: Mon Apr 30 15:45:42 2018
OS/Arch: linux/amd64
Experimental: false
Static hostname: node
Icon name: computer-server
Chassis: server
Machine ID: <machine_id>
Boot ID: <boot_it>
Operating System: OpenShift Enterprise
CPE OS Name: cpe:/o:redhat:enterprise_linux:7.5:GA:server
Kernel: Linux 3.10.0-862.3.3.el7.x86_64
Architecture: x86-64

jib-maven-plugin Configuration:

        <plugin>
          <groupId>com.google.cloud.tools</groupId>
          <artifactId>jib-maven-plugin</artifactId>
          <version>0.9.2</version>
          <configuration>
            <allowInsecureRegistries>true</allowInsecureRegistries>
            <from>
              <image>my.local/registry/openjdk:8-alpine</image>
            </from>
            <to>
              <image>my.local/registry/${project.artifactId}:${project.version}</image>
            </to>
            <container>
              <ports>
                <port>8080</port>
                <port>8081</port>
              </ports>
              <jvmFlags>-Djava.security.egd=file:/dev/./urandom</jvmFlags>
            </container>
          </configuration>
        </plugin>

Log output:
Error: Could not find or load main class my.package.Application

[coollog]

Hi @ssoerensen , are the files in your Maven build output (target/classes) set to 0700?

[qvistgaard]

No, they are set to 0775, but have in mind, it is working as intended with docker version 18.03.1-ce but not with 1.13.1

[coollog]

@ssoerensen Hmm, is there a reason for using this old version?

[qvistgaard]

The reason for running a old version is Redhat, that is what they "support". Anyway i did some messing around trying to see if something would change when i rebuild the image using FROM.

FROM registry/jib-build:0.0.1-SNAPSHOT
RUN touch /app/test

Image is build on 18.03.1-ce and run on 1.13.1 Will actually give /app the correct permissions (0755). however all other files and folders inside the /app folder still have wrong permissions.

I did some poking around and the layer files seems to have the 0600:

drwxrwxr-x  3 wayland wayland     4096 Jul 10 11:54 .
drwxrwxr-x 11 wayland wayland     4096 Jul 18 12:13 ..
-rw-------  1 wayland wayland      419 Jul 10 08:07 90bbc1e3803f15073b2d5245fdec4ca329a79f97d6431ecd4069ca793694635a.tar.gz
drwxrwxr-x  5 wayland wayland     4096 Jul 10 11:55 app
-rw-------  1 wayland wayland     1581 Jul 10 08:07 b585564e9fcebe9cd51391bd457b3db4a737e943cebf162caf9e7e8bc522c00e.tar.gz
-rw-------  1 wayland wayland 15648900 Jul 10 08:07 bc9c232826addf797ce0b20c7ecc77cf164ff06d6696543752a9ac010dd31698.tar.gz
-rw-rw-r--  1 wayland wayland        0 Jul 10 08:07 .jib
-rw-rw-r--  1 wayland wayland    11318 Jul 18 12:11 metadata.json

Could that be the problem?

[chanseokoh]

@ssoerensen we'll have to look into this, but it seems like you are familiar with Docker and at least you can work around this, e.g., by manipulating the image locally?

BTW, if you want to see how Jib would create Dockerfile, you can do mvn jib:exportDockerContext and go to target/jib-docker-context. (You can actually build an image yourself in that directory.) The Dockefile will look like

FROM gcr.io/distroless/java

COPY libs /app/libs/
COPY resources /app/resources/
COPY classes /app/classes/

ENTRYPOINT ["java","-cp","/app/libs/*:/app/resources/:/app/classes/","org.springframework.samples.petclinic.PetClinicApplication"]
CMD []

I wonder if RUN chmod -R go+r /app would work on 1.13.1.

[qvistgaard]

@chanseokoh Yeah, we can work around it for now. It's not like we can't build images. We are just hungering for getting out of the fact that we need dockerd to build images. But let me know if you want me to test any changes :-)

[coollog]

I believe the solution may be to explicitly add entries for the directories (like /app) into the tarballs we generate for the image with permissions set to 0755.

[coollog]

Hi @ssoerensen , I'm trying a fix in #772. Would you mind trying that fix to see if it works for your error?

1. Clone the jib repo: git clone https://github.com/GoogleContainerTools/jib
2. Check out the branch git checkout add-extraction-path-to-tar
3. Install the SNAPSHOT version: cd jib/jib-maven-plugin && ./mvnw install
4. Use the 0.9.9-SNAPSHOT version in your project.

[chanseokoh]

Install the SNAPSHOT version: cd jib/jib-maven-plugin && ./mvnw install

./mvnw -DskipTests install if tests are not passing.

[chanseokoh]

I set up a Docker container that has docker 1.13.1 inside it (in other words, "docker-in-docker"): francium25/jib-and-old-docker-in-docker:1.0

You can pull and run the image, build inside the container the sample helloworld with Jib using the old Docker, and check the permissions for "group" and "others" are indeed not set.

# --privileged required
$ docker run --privileged --name my-container -d francium25/jib-and-old-docker-in-docker:1.0 dockerd
$ docker exec -it my-container sh

(inside container)$ cd jib/examples/helloworld
(inside container)$ mvn -U compile jib:dockerBuild

At this point, Jib has built and pushed an image name called gcr.io/jane/doe to the local Docker daemon (1.13.1, the daemon inside the container). When looking into the built image, directly inside the container,

(inside container)$ docker run --name reproduced -d gcr.io/jane/doe
(inside container)$ docker exec reproduced ls -al /app
total 20
drw-------    5 root     root          4096 Aug 10 19:33 .
drwxr-xr-x   19 root     root          4096 Aug 10 19:40 ..
drw-------    3 root     root          4096 Aug 10 19:33 classes
drw-------    2 root     root          4096 Aug 10 19:33 libs
drw-------    2 root     root          4096 Aug 10 19:33 resources

What's interesting is that, if I upload that image to Docker Hub for later examination,

(inside container)$ docker tag gcr.io/jane/doe francium25/built-with-jib-and-old-docker
(inside container)$ docker login
... log in ...
(inside container)$ docker push

and then pull it and save it locally in my host (i.e., outside the container) and run it, the permissions are set.

$ docker run --name from-uploaded -d francium25/built-with-jib-and-old-docker
$ docker exec from-uploaded ls -al /app
total 20
drwxr-xr-x    1 root     root          4096 Aug 10 19:51 .
drwxr-xr-x    1 root     root          4096 Aug 10 19:51 ..
drwxr-xr-x    3 root     root          4096 Aug 10 19:51 classes
drwxr-xr-x    2 root     root          4096 Aug 10 19:51 libs
drwxr-xr-x    2 root     root          4096 Aug 10 19:51 resources

[chanseokoh]

BTW, the image francium25/jib-and-old-docker-in-docker:1.0 was built by the following Dockerfile. I patched up Jib to disable the cross-repo blob mount and the sample helloworld so that mvn jib:build on the sample just works.

FROM ubuntu:16.04
  
RUN apt-get update && \
    apt-get install -y kmod apt-transport-https software-properties-common \
      vim openjdk-8-jdk maven python git curl && \
    add-apt-repository \
      "deb https://apt.dockerproject.org/repo/ ubuntu-xenial main" && \
    apt-get update && \
    apt-get install -y --allow-unauthenticated \
      docker-engine=1.13.1-0~ubuntu-xenial && \
    git clone https://github.com/GoogleContainerTools/jib.git && \
    cd jib && git checkout disable-cross-repo-blob-mount && \
    cd jib-maven-plugin && mvn -DskipTests install

CMD sleep infinity

[qvistgaard]

@coollog I finally got around to test the patch. i can confirm that the permissions are now correct

[coollog]

@ssoerensen Great! We'll have the patch available in the next version (version 0.9.10).

[coollog]

@ssoerensen We have released version 0.9.10!