Wenzel / docker-kdesrc-build

Dockerfiles to compile KDE source code into Docker with kdesrc-build script
GNU General Public License v2.0
47 stars 21 forks source link

Work directory wrong permissions #5

Closed filcuc closed 9 years ago

filcuc commented 9 years ago

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?

Wenzel commented 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 !

filcuc commented 9 years ago

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 :)

Wenzel commented 9 years ago

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 :)

filcuc commented 9 years ago

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.

Wenzel commented 9 years ago

This could solve this issue. If you would like to do it, then go, and make a pull request ;)