Specify the ownership of new files created in the mounted volume.

[SnowRipple]

Hi there,

I checked other posts but I can't find anything that would address this issue so decided to create a new post. My docker knowledge is still very limited so please be understanding.

The ability to load volumes using "-v" is great however limited from my perspective. I would like to be able to specify the owner of new files created inside mounted volumes. Currently, root is owning all new files and that is problematic since the "not sudo" user can't access those files.

I was thinking about something similar to the way sshfs works when you can specify the ownership by using "-o idmap=user" option e.g.

sshfs -o idmap=user exampleUser@172.1.1.1:/home/directory ~/remote_repo

Now e.g. if I will create "foo" file in "remote_repo" and check its ownership on host's home/directory the owner will be "exampleUser".

When I would mount it using docker volumes the owner of "foo" file would be root which is problematic for non-sudo users.

Btw, are you planning to introduce network addressable volumes (as above in the sshfs example) in the near future?

[jpetazzo]

Hi,

If you chown the volume to the appropriate user, this user should be able to read/write files on the volume.
Would that work for you?

If you really need some kind of remapping, you will have to wait until we merge "user namespace" capabilities (it's a feature to address that need, but it's still bleeding edge).

I'm not sure that I understand exactly what you mean by "network addressable volumes"; if you could send an e-mail to the docker-user mailing list, that would be the right place to start a discussion about it!

Thank you!

[SnowRipple]

Thanks for the reply @jpetazzo!

I was not aware of the docker-user mailing list, I will definitely use it in the future for such issues! (I am still learning the ropes).

If I understand correctly the "chown" can be performed by root or sudo user. Moreover within a container you can chown a file to a user which is present both on the host and in the container, so you can't chown to the user that does not exist in a container.

Thanks for pointing to the "user namespace". I found this on the Docker Blog:

"The end goal for Docker is therefore to implement two additional security improvements:

1.Map the root user of a container to a non-root user of the Docker host, to mitigate the effects of a container-to-host privilege escalation;
2...."

When can we expect this feature to be implemented? ETA?

As for the "network addressable volumes": I just thought that it would be nice if we could use "docker run -v" option to mount a volume that is not necessary on the host but somewhere in the network(network addressable) as in the case of sshfs when you specify the address e.g. "exampleUser@172.1.1.1:/home/directory".

[jpetazzo]

User namespace

If I understand correctly your use-case:

• you are running something as root within the container
• you have a bind-mounted volume, used to share files between host and container
• when the container creates files in the volume, they are owned by root
• in the host, you want non-root processes to handle the files

If that's correct, then user namespaces will help, since they allow to define a mapping, e.g. "UID 0 in container X should be mapped to UID Y in the host". However, I don't have a timeline for that feature, sorry!

Meanwhile, however, if you want the files to be readable by UID 1000 in the host, you could run the processes as UID 1000 in the container. Would that be acceptable?

Network addressable volumes

I believe that this could be a fit for the future plugin API. E.g. a plugin would be able to look at the volume list, and say "hey, I see that this volume starts with sshfs://user@host:... so I should do some FUSE magic, mount it to e.g. /var/lib/docker/plugins/sshfs/user@host/..., then rewrite it so that the Docker runtime can handle it like a normal volume".

Unfortunately, I don't have an ETA for that neither.
For now, this would be the work of additional tooling.

[SnowRipple]

Thanks for the exhaustive response @jpetazzo!

Meanwhile, however, if you want the files to be readable by UID 1000 in the host, you could run the processes as >UID 1000 in the container. Would that be acceptable?
I
t's funny that you mentioned this because I have discovered "run -u" just couple days ago as well. Not sure if this covers all my use cases yet but definitely helps a lot!

Next time will use the mailing list for such issues.

[danielrhodeswarp]

Yep, NFS-style setting and overriding of users and groups for file access and creation would surely be useful here. Especially when using Docker for development. Thanks.