Closed filcuc closed 9 years ago
Hi !
The problem here is that, depending on the host distro, you could have a different uid from the kdedev uid (1000
) in the container.
Most of the time it will not be an issue since the uid 1000
is affected to the first system user created on major distros.
But to illustrate this issue,Fedora is my main system, and my uid is 1006
-> id
uid=1000(wenzel)
So i get a permission denied
too in the container and I had to set the permission manually.
If you really would like to fix this in for docker-kdesrc-build
you would have to check in run.py
which distro is being built, and make an exception for systems like Fedora, and set the correct uid.
Thank you for pointing this out !
i'm not expert in docker but can we add the following command to the list of other executed by docker inside the container (and executed by root): chown kdedev:kdedev /work
or am i missing something? otherwise i think we can close this one :)
The effective permission for a volume are determined when the volume will be mounted, so when the container is starting.
Even if you set the correct permission in the Dockerfile, they will be overwritten.
Consider the following Dockerfile :
FROM debian:latest
RUN useradd -d /home/user01 -m user01
RUN useradd -d /home/user02 -m user02
USER user02
RUN id
VOLUME /toto
USER root
RUN chown user02:user02 /toto
RUN ls -ln /
it gives the following output :
docker build -t test --no-cache .
Sending build context to Docker daemon 3.584 kB
Sending build context to Docker daemon
Step 0 : FROM debian:latest
---> bf84c1d84a8f
Step 1 : RUN useradd -d /home/user01 -m user01
---> Running in c20fbf6bba85
---> 06f391c82b36
Removing intermediate container c20fbf6bba85
Step 2 : RUN useradd -d /home/user02 -m user02
---> Running in 769744fee3a9
---> f809d9f37414
Removing intermediate container 769744fee3a9
Step 3 : USER user02
---> Running in fcc5d2260907
---> 7666102a29f7
Removing intermediate container fcc5d2260907
Step 4 : RUN id
---> Running in 7a4d7c9b3394
uid=1001(user02) gid=1001(user02) groups=1001(user02)
---> 0c54979ae9d5
Removing intermediate container 7a4d7c9b3394
Step 5 : VOLUME /toto
---> Running in 523a02723b9f
---> e63f4744fabc
Removing intermediate container 523a02723b9f
Step 6 : USER root
---> Running in 5954b1b866e6
---> 1ec2305ade44
Removing intermediate container 5954b1b866e6
Step 7 : RUN chown user02:user02 /toto
---> Running in 3ab176cece20
---> 59e85c8df8f6
Removing intermediate container 3ab176cece20
Step 8 : RUN ls -ln /
---> Running in 38b61da0dfec
total 68
drwxr-xr-x. 2 0 0 4096 Jun 15 18:37 bin
drwxr-xr-x. 2 0 0 4096 May 4 13:20 boot
drwxr-xr-x. 5 0 0 360 Sep 7 09:18 dev
drwxr-xr-x. 41 0 0 4096 Sep 7 09:18 etc
drwxr-xr-x. 4 0 0 4096 Sep 7 09:17 home
drwxr-xr-x. 9 0 0 4096 Nov 27 2014 lib
drwxr-xr-x. 2 0 0 4096 Jun 15 18:33 lib64
drwxr-xr-x. 2 0 0 4096 Jun 15 18:32 media
drwxr-xr-x. 2 0 0 4096 Jun 15 18:32 mnt
drwxr-xr-x. 2 0 0 4096 Jun 15 18:32 opt
dr-xr-xr-x. 283 0 0 0 Sep 7 09:18 proc
drwx------. 2 0 0 4096 Jun 15 18:32 root
drwxr-xr-x. 3 0 0 4096 Jun 15 18:32 run
drwxr-xr-x. 2 0 0 4096 Jun 15 18:37 sbin
drwxr-xr-x. 2 0 0 4096 Jun 15 18:32 srv
dr-xr-xr-x. 13 0 0 0 Sep 7 2015 sys
drwxrwxrwt. 2 0 0 4096 Jun 15 18:37 tmp
drwxr-xr-x. 2 0 0 4096 Sep 7 09:18 toto
drwxr-xr-x. 10 0 0 4096 Jun 15 18:32 usr
drwxr-xr-x. 11 0 0 4096 Jun 15 18:32 var
---> 8d2d8bd99805
Removing intermediate container 38b61da0dfec
Successfully built 8d2d8bd99805
I set the permission of /toto
to user02, so 1002:1002
.
This is the directory that I would like to be mounted from my host system:
ls -ln
drwxr-xr-x. 2 1000 1002 4,0K 7 sept. 05:05 toto
-rw-r--r--. 1 1000 1002 181 7 sept. 05:13 Dockerfile
and now if I run the container and mount the volume :
docker run --rm -it -v $(pwd)/toto/:/toto test
root@f3007f487339:/# ls -l /
drwxr-xr-x. 2 root root 4096 Jun 15 18:37 bin
drwxr-xr-x. 2 root root 4096 May 4 13:20 boot
drwxr-xr-x. 5 root root 380 Sep 7 09:20 dev
drwxr-xr-x. 41 root root 4096 Sep 7 09:20 etc
drwxr-xr-x. 4 root root 4096 Sep 7 09:17 home
drwxr-xr-x. 9 root root 4096 Nov 27 2014 lib
drwxr-xr-x. 2 root root 4096 Jun 15 18:33 lib64
drwxr-xr-x. 2 root root 4096 Jun 15 18:32 media
drwxr-xr-x. 2 root root 4096 Jun 15 18:32 mnt
drwxr-xr-x. 2 root root 4096 Jun 15 18:32 opt
dr-xr-xr-x. 284 root root 0 Sep 7 09:20 proc
drwx------. 2 root root 4096 Jun 15 18:32 root
drwxr-xr-x. 3 root root 4096 Jun 15 18:32 run
drwxr-xr-x. 2 root root 4096 Jun 15 18:37 sbin
drwxr-xr-x. 2 root root 4096 Jun 15 18:32 srv
dr-xr-xr-x. 13 root root 0 Sep 7 2015 sys
drwxrwxrwt. 2 root root 4096 Jun 15 18:37 tmp
drwxr-xr-x. 2 user01 1002 4096 Sep 7 09:05 toto
drwxr-xr-x. 10 root root 4096 Jun 15 18:32 usr
drwxr-xr-x. 11 root root 4096 Jun 15 18:32 var
as you can see the volume /toto
has the permission of the host directory !
So you have to find a way to set the correct permissions when you run the container, not when you are building the image :)
i thinked about a workaround but it's horrible: The idea could be to create a script and execute it automatically by adding it to the .bashrc of the kdedev user. This script should test the /work directory and eventually change ownership. This will be execute when the user logs in.
This could solve this issue. If you would like to do it, then go, and make a pull request ;)
I tried this container today with an archlinux base image. The kdesrc-build script fails due to wrong permissions in the /work directory I fixed it by running sudo chown -R kdedev:kdedev /work It is it a bug or is it meant to be run with sudo?