kaniko
kaniko copied to clipboard
GoogleContainerTools
directory permissions change
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:
- Base image test/jdk.18
app directory permissions app: app - 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 |
|
Hi @ibayue, this sounds very much like https://github.com/GoogleContainerTools/kaniko/issues/9.
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?
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.
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/
Just retested without the / - same error.
ls -ld /opt/opendj
drwxr-xr-x 1 root root 4096 Mar 11 16:55 /opt/opendj
@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
OK @maxres-fr good to know, we'll try to test soon the supposedly fixed COPY --chown.
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)
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?
@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.
Is it possible to merge #1257 ? I have the same permissions problems with the parent folder of my COPY --chown command.
0.24 has something like this still. My chowns on directories are not taking
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
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.
