New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

empty VOLUME is very restricted: root:root 700 #2969

Closed
SvenDowideit opened this Issue Nov 30, 2013 · 14 comments

Comments

Projects
None yet
9 participants
@SvenDowideit
Copy link
Contributor

SvenDowideit commented Nov 30, 2013

Is there really no way to set ownership and permissions of a VOLUME?

~ $ docker build -t test -
FROM ubuntu
RUN mkdir /data ; chmod 777 /data
VOLUME ["/data"]
RUN chmod 755 /data

Uploading context 2048 bytes
Step 1 : FROM ubuntu
 ---> 8dbd9e392a96
Step 2 : RUN mkdir /data ; chmod 777 /data
 ---> Using cache
 ---> 5e2d567c32ef
Step 3 : VOLUME ["/data"]
 ---> Using cache
 ---> d2832c4afd2c
Step 4 : RUN chmod 755 /data
 ---> Running in 34b05587ce60
 ---> 7c4d94ba6eed
Successfully built 7c4d94ba6eed
~ $ docker run -t -i test ls -la /data
total 8
drwx------  2 root root 4096 Nov 30 09:25 .
drwxr-xr-x 37 root root 4096 Nov 30 09:25 ..

I'm making a container which will run something that does not want to run as root, so 700 is particularly frustrating.

somewhat related to #1742 and #2088

@SvenDowideit

This comment has been minimized.

Copy link
Contributor

SvenDowideit commented Nov 30, 2013

it seems that so long as you create a file in the dir, the VOLUME gets the permission you want - I think thats a reasonably simple small bug - and clearly a stack of buildfile_test tests needed

docker build -t test .
Uploading context 10240 bytes
Step 1 : FROM ubuntu
 ---> 8dbd9e392a96
Step 2 : RUN mkdir /data
 ---> Using cache
 ---> db1322ff4655
Step 3 : RUN chmod 555 /data
 ---> Using cache
 ---> 005372af3b9a
Step 4 : RUN echo ttt > /data/ttt
 ---> Using cache
 ---> a981801d33c9
Step 5 : RUN chmod 666 /data/ttt
 ---> Using cache
 ---> de66db385699
Step 6 : VOLUME ["/data"]
 ---> Using cache
 ---> a0682696f924
Step 7 : USER www-data
 ---> Running in f701b23626ae
 ---> a55a446b1d5c
Step 8 : CMD ls -la /data
 ---> Running in fdecd4714f63
 ---> 5db5753c6cb9
Successfully built 5db5753c6cb9
test-volume(master) $ docker run test
total 12
dr-xr-xr-x  2 root root 4096 Nov 30 11:35 .
drwxr-xr-x 50 root root 4096 Nov 30 11:37 ..
-rw-rw-rw-  1 root root    4 Nov 30 11:35 ttt
@SvenDowideit

This comment has been minimized.

Copy link
Contributor

SvenDowideit commented Nov 30, 2013

see graphdriver/vfs/driver.go line 51 - the mkdir uses a hardcoded perm, and (i presume there is no parent to copy from if the parent is empty)

@jpetazzo

This comment has been minimized.

Copy link
Contributor

jpetazzo commented Dec 2, 2013

Right! I also wonder if having the VOLUME command before or after might change something.
If you add some tests for that, it might be interesting to check that case too?

@ndarilek

This comment has been minimized.

Copy link
Contributor

ndarilek commented Dec 2, 2013

Could this be related to #2049 as well? I hit a very similar issue when attempting to put non-root-owned directories inside volumes.

@SvenDowideit

This comment has been minimized.

Copy link
Contributor

SvenDowideit commented Dec 3, 2013

@jpetazzo ouch - the tests in the PR above show a number of failures, including

FROM {IMAGE}
VOLUME ["/data"]
RUN mkdir /data ; chmod 777 /data ; chown 1000:1001 /data
RUN echo ttt > /data/ttt
RUN chmod 666 /data/ttt
CMD stat /data -c '%s %f %F %G %U %a %n'

returns

        The command [/bin/sh -c chmod 666 /data/ttt] returned a non-zero code: 1

wking added a commit to wking/dockerfile that referenced this issue Jan 3, 2014

postgresql: Declare /var/lib/postgresql a VOLUME
Avoid the hassle of maintaining a host-mounted volume by letting
Docker handle the volume maintenance ;).  We need to declare the
VOLUME *after* filling it with content (with 'emerge --config'),
otherwise ownership and permissions on the empty volume are lost
[1,2,3], and future RUN commands die due to:

  initdb: could not access directory "/var/lib/postgresql/9.3/data": Permission denied

[1]: moby/moby#2360
[2]: moby/moby#2969
[3]: moby/moby#2975
[4]: moby/moby#3008
@shykes

This comment has been minimized.

Copy link
Collaborator

shykes commented Feb 13, 2014

@SvenDowideit should we use the current value of USER in the Dockerfile and set the ownership of the volume to that?

@SvenDowideit

This comment has been minimized.

Copy link
Contributor

SvenDowideit commented Feb 14, 2014

it seems like what the user would expect - that setting the USER is like su -

which is also why people ask about $HOME :/

pirog added a commit to pirog/kaladata-docker that referenced this issue May 21, 2014

@iwinux

This comment has been minimized.

Copy link

iwinux commented Jun 30, 2014

+1 for chown volume to USER

@nugend

This comment has been minimized.

Copy link

nugend commented Sep 8, 2014

#2975, #2360, #6047, #5080 and maybe a few others seem to be about this, and are closed. Fix was reported in #5136, but I'm still seeing the issue in docker 1.2.0 build fa7b24f

Is this maybe an environment issue? Something specific to a kernel version?

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Sep 8, 2014

@nugend Are you using this conjunction with "-v /host/path:/container/path" ?

@nugend

This comment has been minimized.

Copy link

nugend commented Sep 8, 2014

Nope. Straight data volume. What additional info can I provide for reproduction?

@roytruelove

This comment has been minimized.

Copy link

roytruelove commented Sep 10, 2014

+1. I used #2969 (comment) as a workaround

@pirog

This comment has been minimized.

Copy link

pirog commented Sep 10, 2014

+1

On Wed, Sep 10, 2014 at 1:41 PM, Roy Truelove notifications@github.com
wrote:

+1


Reply to this email directly or view it on GitHub
#2969 (comment).

Cheers,

Mike Pirog
Kalamuna
www.kalamuna.com

@cpuguy83

This comment has been minimized.

Copy link
Contributor

cpuguy83 commented Feb 20, 2015

So this was definitely fixed way back, I cannot reproduce.
Closing, but if you can provide a way to repro this (prefferably with a Dockerfile + run command), please ping here!

FROM busybox
RUN mkdir -p /data && chmod 777 /data && chown 1000:1000 /data
VOLUME /data
CMD ls -lh /
docker run -it --rm test
total 52
drwxrwxr-x    2 root     root        4.0K Feb 20 19:43 bin
drwxrwxrwx    2 default  default     4.0K Feb 20 19:43 data
drwxr-xr-x    5 root     root         380 Feb 20 19:43 dev
drwxr-xr-x    1 root     root        4.0K Feb 20 19:43 etc
drwxrwxr-x    4 root     root        4.0K Feb 20 19:43 home
drwxrwxr-x    2 root     root        4.0K Feb 20 19:43 lib
lrwxrwxrwx    1 root     root           3 May 22  2014 lib64 -> lib
lrwxrwxrwx    1 root     root          11 May 22  2014 linuxrc -> bin/busybox
drwxrwxr-x    2 root     root        4.0K Feb 27  2014 media
drwxrwxr-x    2 root     root        4.0K Feb 27  2014 mnt
drwxrwxr-x    2 root     root        4.0K Feb 27  2014 opt
dr-xr-xr-x  125 root     root           0 Feb 20 19:43 proc
drwx------    2 root     root        4.0K Feb 20 19:43 root
lrwxrwxrwx    1 root     root           3 Feb 27  2014 run -> tmp
drwxr-xr-x    2 root     root        4.0K Feb 20 19:43 sbin
dr-xr-xr-x   13 root     root           0 Feb 20 19:43 sys
drwxrwxrwt    3 root     root        4.0K Feb 20 19:43 tmp
drwxrwxr-x    6 root     root        4.0K Feb 20 19:43 usr
drwxrwxr-x    4 root     root        4.0K Feb 20 19:43 var
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment