directory permissions change

[ibayue]

Actual behavior A clear and concise description of what the bug is.

Expected behavior A clear and concise description of what you expected to happen.

To Reproduce Steps to reproduce the behavior:

1. Base image test/jdk.18 app directory permissions app: app
2. new images app and app/lib directory permissions is change to root ,why? Same dockerfile if i use docker build , the new images app and app/lib is not change ,This is what we need。

Additional Information

• Dockerfile

  FROM test/jdk:1.8
  COPY --chown=app.app 1.txt /app/lib/

• Build Context docker run --env DOCKER_CONFIG=/kaniko -v /tmp/app:/workspace -v /root/.docker/config.json:/kaniko/config.json gcr.io/kaniko-project/executor:latest -d reg.xx.com/mid/test

• Kaniko Image (fully qualified with digest) gcr.io/kaniko-project/executor:latest

  Triage Notes for the Maintainers

  Description	Yes/No
  Please check if this a new feature you are proposing	- [ ]
  Please check if the build works in docker but not in kaniko	- [ ]
  Please check if this error is seen when you use --cache flag	- [ ]
  Please check if your dockerfile is a multistage dockerfile	- [ ]

[ataillefer]

Hi @ibayue, this sounds very much like https://github.com/GoogleContainerTools/kaniko/issues/9.

[ibayue]

Hi, thank you @ataillefer I use chown in Dockerfile,stdout can see app directory is app:app,but the images app directory is also root:root!,why?

[ataillefer]

Don't know, can you please provide the new Dockerfile?

[tejal29]

We need to reproduce this bug to make sure this still exists.

[cvgw]

Is this related to https://github.com/GoogleContainerTools/kaniko/issues/721?

[wstrange]

This bug still exists in v0.18.0

For example, this: https://github.com/ForgeRock/forgeops/tree/master/docker/7.0/ds/idrepo

Results in /opt/opendj being owned by root, instead of the "forgerock" user in the parent image.

The same image built with docker works fine (/opt/opendj remains owned by the forgerock user)

If we add flags: [ "--single-snapshot" ] to our skaffold file, the directory ownership is OK.

[ataillefer]

Just a quick check, does it behave the same without the final slash in the target directory?

COPY --chown=forgerock:root .  /opt/opendj

instead of

COPY --chown=forgerock:root .  /opt/opendj/

[wstrange]

Just retested without the / - same error.

ls -ld /opt/opendj
drwxr-xr-x 1 root root 4096 Mar 11 16:55 /opt/opendj

[maxres-fr]

@ataillefer based on my debugging the issue is related to snapshots and not the builds. You can add a ls -la right after the copy command and it show the correct ownership. Can see some of my comments in slack too https://kubernetes.slack.com/archives/CQDCHGX7Y/p1583438179027700

[ataillefer]

OK @maxres-fr good to know, we'll try to test soon the supposedly fixed COPY --chown.

[bitsofinfo]

similar issue, builds that work fine built w/ normal Docker, get weird permissions errors after being built by Kaniko. (tried 0.15.x + 0.18.0)

[kevinleturc]

Hello,

We've got a similar issue with an image extending another one. We used kaniko v0.18.0. The base image has a USER ... at the end of its Dockerfile.

Here below the corresponding Dockerfile:

# vim:set ft=dockerfile:
# ------------------------------------------------------------------------
FROM nuxeo/nuxeo:10.10

COPY --chown=nuxeo:root some-config.xml /opt/nuxeo/server/nxserver/config/
RUN ls -la /opt/nuxeo/server/nxserver/config
RUN ls -la /opt/nuxeo/server/nxserver
RUN ls -la /opt/nuxeo/server

The output of ls -la /opt/nuxeo/server/nxserver/config:

drwxr-xr-x 2 root  root 4096 Mar 12 11:12 .
drwxrwxr-x 6 nuxeo root 4096 Mar 12 11:12 ..
-rw-r--r-- 1 nuxeo root  305 Mar 12 11:12 nuxeo-arender-low-resolution-contrib.xml

So the file is copied with the right permission. But as you can see with ., its parent's ownership has changed.

The output of ls -la /opt/nuxeo/server/nxserver:

drwxr-xr-x  3 nuxeo nuxeo  4096 Mar 13 11:33 META-INF
-rw-rw-r--  1 nuxeo root  37519 Jan 21  2019 artifacts-server.properties
drwxrwxr-x  1 nuxeo root  16384 Mar 13 11:33 bundles
drwxr-xr-x  1 root  root   4096 Mar 13 11:33 config
drwxrwxr-x  2 nuxeo root   4096 Jan 21  2019 data
-rw-r--r--  1 nuxeo nuxeo    34 Mar 13 11:33 launcher.properties
drwxrwxr-x  1 nuxeo root   4096 Mar 13 11:33 lib
drwxr-xr-x 10 nuxeo nuxeo  4096 Mar 13 11:33 nuxeo.war
drwxr-xr-x  2 nuxeo nuxeo  4096 Mar 13 11:33 plugins
-rw-rw-r--  1 nuxeo root     73 Jan 21  2019 system.properties
-rw-rw-r--  1 nuxeo root    422 Jan 21  2019 test-artifacts-server.properties
drwxr-xr-x  3 nuxeo nuxeo  4096 Mar 13 11:33 tmp
drwxr-xr-x  3 nuxeo nuxeo  4096 Mar 13 11:55 web

We clearly see that config directory has root:root ownership while it is nuxeo:nuxeo in base image.

The output of ls -la /opt/nuxeo/server:

drwxrwxr-x 15 nuxeo root  4096 Mar 12 11:12 .
drwxr-xr-x  3 root  root  4096 Mar 12 11:12 ..
-rw-rw-r--  1 nuxeo root 19764 Jan 21  2019 BUILDING.txt
-rw-rw-r--  1 nuxeo root  6242 Jan 21  2019 CONTRIBUTING.md
-rw-rw-r--  1 nuxeo root   639 Jan 21  2019 LICENSE.txt
-rw-rw-r--  1 nuxeo root  3334 Jan 21  2019 README.md
-rw-rw-r--  1 nuxeo root  6536 Jan 21  2019 README.txt
-rw-rw-r--  1 nuxeo root   210 Jan 21  2019 Start Nuxeo.bat
-rwxrwxr-x  1 nuxeo root   148 Jan 21  2019 Start Nuxeo.command
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 bin
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 client
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 conf
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 doc-tomcat
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 lib
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 licenses
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 log
drwxrwxr-x  6 nuxeo root  4096 Mar 12 11:12 nxserver
drwxrwxr-x  4 nuxeo root  4096 Mar 12 11:12 packages
-rw-rw-r--  1 nuxeo root  7325 Jan 21  2019 readme.html
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 setupWizardDownloads
drwxrwxr-x 26 nuxeo root  4096 Mar 12 11:12 templates
drwxrwxr-x  2 nuxeo root  4096 Mar 12 11:12 tmp
drwxrwxr-x  5 nuxeo root  4096 Mar 12 11:12 webapps

We can see that nxserver ownership is still nuxeo:root which is the expected behavior. Note: this wasn't the case prior to v0.18.0, all arborescence was changed.

@maxres-fr what is the next step on this topic?

[maxres-fr]

@kevinleturc I'm not entirely sure here. Using --single-snapshot should help resolved in v0.18.0, I've had successful results with v0.16.0. Im not familiar with the kaniko code base and I'm not sure this would be a good issue for me as a first time contrib, unless someone has some pointers on where to get started.

It's great to see the issue reproduced.

I've tried to debug a little of this, but my hunch is that it's related to the snapshots and not the COPY or at least not directly related command but I don't want to lead anyone down the wrong path.

FWIW @wstrange and I work on the same code bases.

[tomprince]

I think this is a duplicate of #1163 (fixed in #1166).

[irizzant]

Is it possible to merge #1257 ? I have the same permissions problems with the parent folder of my COPY --chown command.

[kevinleturc]

Hello, Do you know when #1257 would be merged?

[bitsofinfo]

0.24 has something like this still. My chowns on directories are not taking

[hobti01]

in 0.24.0 I also see:

ENV SOME_DIR=/var/run/foo
RUN mkdir -p ${SOME_DIR} && chown -R 65534:65534 ${SOME_DIR}

In the resulting image:

$ ls -al /var/run
total 12
drwxr-xr-x 3 root root 4096 Jan  1  1970 .
drwxr-xr-x 1 root root 4096 Jan  1  1970 ..
drwxrwxrwx 2 root root 4096 Jan  1  1970 foo

edit: This is with --snapshotMode=redo

[JonathanRRogers]

I am still encountering this behavior in 0.22.0 (#1166 was first released in 0.20.0). Specifically, I'm seeing directories becoming owned by root after files under the directory are added. Additionally, as @bitsofinfo mentioned, chowning the directory does not fix ownership of the directory. Adding --single-snapshot does avoid the problem.