dont append user and selinux flags on windows slaves
Workaround for some issues when running windows containers.
- Don't append SELinux flag
- Don't set the user as Windows doesn't like the Unix uids
- Don't add docker top arguments on windows
@svanoort do recall you saying that this only works if the master is also on windows?
In our environment the master is on Linux (CentOS 7). We only have some Windows slaves used for Docker
How does windows container handle file permissions on volumes ?
Passing --user is required to ensure the process ran inside container do create files on workspace with adequate owner on host. I wonder how windows behave if a container do define a custom user, which doesn't actually exist on host, and create a read only file on a share volume.
I don't know exactly how windows treats users in containers as we are only using the built-in "ContainerAdministrator" that only exist in the container. All files created by this user have the following permissions in the workspace:
Owner Access
----- ------
BUILTIN\Administrators NT AUTHORITY\SYSTEM Allow FullControl...
We have inheritance enabled on the workspace folder on the slave so all files get the group of the service user on the host and have ReadWrite permissons for this group. This is basically a workaround for not having AD users in the container. Alternatively it would be possible to add the service user to the Administrators group.
The only documentation I found was https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/container-storage#permissions which is not very extensive.
Is it necessary to investigate this in order to get this merged? This pull-request does not aim to provide full featured windows support, rather not actively preventing it from working.
To answer the ACL question, it seems Windows properly inherits file system permissions even if the container cannot figure out who the "IdentityReference" is referring to. It also creates the file with the builtin user group "BUILTIN\Administrators". This means the docker host should by default be able to read/write files generated in a container without issues because in order to use the docker daemon on Windows the user must be in the local Administrators group.
######################################
#On Host
######################################
PS> docker run -dt --rm -v C:\Users\rbutcher\Workspaces\temp\:C:\testing --entrypoint cmd microsoft/windowsservercore:1803
478ecac08c100085cfbb3aaa5c9c005e6a1f81edf415170d36db8d2415d4fba7
PS> docker exec -it 478ec powershell
######################################
#In Container
######################################
PS C:\testing> echo "Testing" > testing.txt
PS C:\testing> (Get-Acl .\testing.txt).Access
FileSystemRights : FullControl
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SYSTEM
IsInherited : True
InheritanceFlags : None
PropagationFlags : None
FileSystemRights : FullControl
AccessControlType : Allow
IdentityReference : BUILTIN\Administrators
IsInherited : True
InheritanceFlags : None
PropagationFlags : None
FileSystemRights : FullControl
AccessControlType : Allow
IdentityReference : S-1-5-21-73586283-688789844-725345543-31458
IsInherited : True
InheritanceFlags : None
PropagationFlags : None
######################################
#On Host
######################################
PS> cd C:\Users\rbutcher\Workspaces\temp\
PS> (Get-Acl .\testing.txt).Access
FileSystemRights : FullControl
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SYSTEM
IsInherited : True
InheritanceFlags : None
PropagationFlags : None
FileSystemRights : FullControl
AccessControlType : Allow
IdentityReference : BUILTIN\Administrators
IsInherited : True
InheritanceFlags : None
PropagationFlags : None
FileSystemRights : FullControl
AccessControlType : Allow
IdentityReference : ONBASE\rbutcher
IsInherited : True
InheritanceFlags : None
PropagationFlags : None
PS> (Get-Acl .\testing.txt).Owner
BUILTIN\Administrators
I opened a similar, but more comprehensive change in PR-148