docker-images icon indicating copy to clipboard operation
docker-images copied to clipboard

Permission issues on Windows

Open embray opened this issue 9 years ago • 1 comments

I've encountered another annoyance that occurs when a directory in Windows is mapped to a shared folder in virtualbox, and subsequently mounted as a volume in a docker container (though really this issue is at the virtualbox layer; not so much an issue with docker).

The problem is that there is no obvious mapping between UNIX-style file permissions and Windows file permissions. There is some discussion about this in virtualbox's trac. What it ends up doing by default is setting all files in the mounted share folder to have a default mode of 777. Actual attempts to read and/or write these files will aren't necessarily affected by these modes, and will depend on the true permissions of the underlying NTFS filesystem. This is annoying and misleading for a few reasons:

  1. File and directory modes don't necessarily mean what they say they mean. In most applications this isn't a problem so long as errors are properly handled in filesystem operations.
  2. All files are marked as executable by default.
  3. Because the default permissions are so permissive, some software complains about that (particularly when mounted as the user's home directory). I ran into this, for example, because Python won't add '' to sys.path if the home directory's permissions are too permissive, as a safety measure. This breaks a common expectation in Python and also produces an annoying warning when starting Python. Sage also outputs a message about trying to fix the permissions on DOT_SAGE (an action which still fails).

It is possible to change the default permissions with the fmode and dmode mount options for the vboxsf filesystem. I will propose for boot2docker that they consider changing these defaults to something less permissive, like 700. Normally I'd say files shouldn't be executable by default either. However, if we didn't mark files as executable, any attempt to do so after the fact fails. This could be confusing if a user tries to run a file that they expect to be executable. That said it could also be a security hazard, so I have mixed feelings.

embray avatar Mar 22 '16 14:03 embray

On the latter issue, it might be sufficient just to tell Windows users that marking a file as "executable" has no meaning on Windows and won't work.

embray avatar Mar 22 '16 14:03 embray