rexray/efs mount point permissions are always mode 700

[agilezebra]

Summary

EFS mount point permissions are always mode 700 when mounted, even after setting the permissions to something else. This is not the behaviour of other docker volumes when mounted, such as the built in named volumes, which default to mode 775 and retain their permissions correctly between mounts, in the same way that a UNIX regular filesystem does.

User and group mode is retained correctly between mounts.

Expected Behavior

Mount points / filesystem root should retain permissions when remounted in the same way as a regular UNIX filesystem or the standard docker named volumes does.

Actual Behavior / Steps To Reproduce

admin@orac:~$ docker volume create --driver rexray/efs --name test
test
admin@orac:~$ docker run -it --rm -v  test:/test ubuntu bash
root@50d3f6fc7ee5:/# ls -ld /test
drwx------ 2 root root 6144 Apr 10 08:38 /test
root@50d3f6fc7ee5:/# chmod 775 /test
root@50d3f6fc7ee5:/# ls -ld /test
drwxrwxr-x 2 root root 6144 Apr 10 08:38 /test
root@50d3f6fc7ee5:/# exit
admin@orac:~$ docker run -it --rm -v  test:/test ubuntu bash
root@99e69102c1a3:/# ls -ld /test
drwx------ 2 root root 6144 Apr 10 08:38 /test
root@99e69102c1a3:/# 

[clintkitson]

Hello @agilezebra,

Have you seen the plugin config options, there is a FILE_MODE setting that can be set via env variable when starting the plugin. I believe this should enable you to change that setting for all volumes.

https://github.com/rexray/rexray/blob/master/.docker/plugins/efs/config.json#L62-L69

[agilezebra]

Thanks Clint. Hadn’t seen. That will probably get us by. Any reason why the plugin doesn’t exhibit the same behaviour as the native volumes or even any other file system and allow us to set a per-filesystem mode as we see fit? A one-size-fits-all mode for all file systems is ok for our needs right now but some may not be able to easily cope with identical permissions on all their mount points.

[clintkitson]

It has a bit to do with the docker model for volumes and storing the information about created volumes. REX-Ray mostly is non-persistent meaning it doesn't store any information about volumes when they are created. So it is up to what calls REX to specify these special options (since it doesn't store them). Docker doesn't have an API currently that passes along this kind of information when launching containers. Platforms like K8s do actually have this functionality where they store information per volume and make the effort to pass more details.

Architecturally REX-Ray aligns to K8s in this fashion where it requires something to always declare what the special options are.

[agilezebra]

But doesn't / in the underlying mounted fs have permissions set that can just be retained (just as the it does for every other directory)? I note that the user:group persist between mounts so why not the mode?

[clintkitson]

First request for that. I believe this is the part of the code that would fix the problems that you are referring to.

https://github.com/rexray/rexray/blob/02e0154f7b41dc6e56bf8b0ec2a131edef115c07/libstorage/drivers/os/linux/linux.go#L135-L136

[agilezebra]

I can't tell for sure as I'm unfamiliar with the code base, but it would seem to be that the chmoding is the the cause of the problem in the first place, rather than the potential solution. Whilst I'm not familiar with how these drivers work, generically when you mount a filesystem on unix, the existing mode and owner of the root of the mounted filesystem hides the existing mode and owner of the mount point. It therefore shouldn't matter what the permissions of the mount point are prior to mounting and no chmod should be needed at all. A chmod for a default mode on the root of a new filesystem after mounting is probably useful when first created; but once the filesystem exists (and we have potentially changed the mode to our requirements) the driver should leave the mode alone thereafter on all subsequent mounts.

[thielj]

@clintkitson, I agree with @agilezebra: If the mount target already exists inside the container, the permissions or ownership must not be touched. Simply remove the call to os.Chmod (and again, further down in the same file). If the target doesn't exist, os.MkdirAll alone will be sufficient:

MkdirAll creates a directory named path, along with any necessary parents, and returns nil, or else returns an error. The permission bits perm (before umask) are used for all directories that MkdirAll creates. If path is already a directory, MkdirAll does nothing and returns nil.

As a crude workaround: it is possible to change the 0700 to something else by passing e.g. LINUX_VOLUME_FILEMODE=0755 when installing the plugin.