introduce ability to create a volume with non-root initial ownership

[ndeloof]

Description

docker volume create always create a volume onwed by root, see https://github.com/moby/moby/blob/master/volume/local/local.go#L155

to be used by a container, until container also runs as root, user has to use some hack-ish scripts to chown volume root.
I suggest the local volume driver adds support for option to define initial uid:gid ownership for a volume.

With this, I could use :

$ docker volume create --driver local --opt uid=1000 data
data
$ docker run --volume data:/data --user 1000 myimage

This is somehow comparable to #2259 but acknowledge the limitations for bind mounts (i.e local volumes created under /var/lib/docker/volumes) regarding remapping of uid/gid

[thaJeztah]

Thanks! So the thing I was thinking about was that the -o options are for mounting the volume, so wondering if they should be part of the --mount options (not a property of the volume). That would also keep the option open for idmapped mounts (once we start supporting them)

[thaJeztah]

Also adding to this (from our discussion on slack);

• the permissions of the volume (effectively the _data directory of the volume, which is the volume's root) should be copied from the target destination in the container
• ^^ IIUC, this feature was for situations where the target directory inside the container doesn't exist in this example;
  • the container would not have a /data directory
  • so the /data directory is created in the container (with default root:root ownership and permissions)
  • the volume is mounted, and its _data directory is created, inheriting those permissions
• Question is; what is the expected behavior if the target directory does exist, and the specified uid does not match ownership of that path?
  • also worth noting that this option would only affect the volume root directory; I wonder if users expect this to do a recursive chown of all files inside the volume (which we likely don't want to do, and for which idmapped mounts would be a better solution);
  • ^^ see Add ability to mount volume as user other than root #2259

[oliv3r]

My concern here is; if I create a service (download compose file, write one myself for an established image), and I add a volume (volume: - service_home:/home/service:rw) as an example, I expect this to 'just work'. (Assuming I do not have some maintainance container, some boostrap/setup script etc).

The only way I would expect this to 'properly' work, is that the permissions are copied from the container mount point, onto _data, which of course does require the container itself to do the right thing beforehand. E.g. install -m 0755 -u user -g group /home/user (to be fair, this is part of adduser ;p).

But how about, if we do voume: - service_config:/home/service/.config and .config doesn't exist yet (not very common to have it existing). Docker will create the target directory, which is good; but what permissions should it use? Ideally, it would inherit at the least, the user/group of the parent. maybe with the ability to override the permission bits? (e.g. restrict .config to 700 during mount.

After re-reading this proposal, I am missing the mode too, so
uid:gid:mode would be needed at the least. oliver:users:0740 for example.

Some inheritance from the target would still work best though. Like the VOLUME keyword behaves in the dockerfile.

e.g. if I mount myvolume:/home/oliver:inherit_perm would set the volume to whatever permissions /home/oliver has in the container image.

Just spilling some thoughts :)