Docker windows containers file access permission issues

Question

Windows Server 2016 host, running Docker EE through the default MSFTdocker provider.

Docker version 17.06.2-ee-5, build 508bb92

docker-compose version 1.17.1, build 6d101fb0

I have a Windows container based on microsoft/windowsservercore:latest, and am attempting to setup an image for Bamboo server. During creation of a build plan, the server generates a cipher to communicate between Bamboo and Bitbucket. In the running container, the cipher folder/file generation fails with the following error:

java.nio.file.AccessDeniedException: C:\bamboo-home\xml-data\configuration\cipher\cipher.key_0

I have tried with the volume C:\bamboo-home both attached to my Windows host, and fully contained inside the container. Same error both times.

Windows containers run with an admininstrator account named 'containeradministrator'; this is the case both in the default image, and when using an entrypoint, as demonstrated below.

Standard image run:

PS C:\> docker run -it microsoft/windowsservercore:latest powershell
Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All
rights reserved.

PS C:\> whoami 
user manager\containeradministrator

And on the custom-built image to test entrypoint:

PS C:\test> docker-compose build
Building testentrypoint
Step 1/2 : FROM microsoft/windowsservercore:latest
---> 2cddde20d95d
Step 2/2 : ENTRYPOINT whoami
---> Running in 7fe31f02e45f
---> 60822e1907f1
Removing intermediate container 7fe31f02e45f
Successfully built 60822e1907f1
Successfully tagged test/entrypoint:latest
PS C:\test> docker-compose up
Creating network "test_default" with the default driver
Creating test_testentrypoint_1 ...
Creating test_testentrypoint_1 ... done
Attaching to test_testentrypoint_1
testentrypoint_1 | user manager\containeradministrator
test_testentrypoint_1 exited with code 0

This user is an alias to Administrator from what I can tell, although interestingly it doesn't show up in net user as this name:

PS C:\> net user

User accounts for \\

-------------------------------------------------------------------------------
Administrator            DefaultAccount           Guest
The command completed with one or more errors.

So this is potentially an issue, but regardless, the user has full admin permissions from what I can tell:

PS C:\> $user = [Security.Principal.WindowsIdentity]::GetCurrent()
PS C:\> $user

AuthenticationType : Negotiate
ImpersonationLevel : None
IsAuthenticated    : True
IsGuest            : False
IsSystem           : False
IsAnonymous        : False
Name               : User Manager\ContainerAdministrator
Owner              : S-1-5-93-2-1
User               : S-1-5-93-2-1
Groups             : {S-1-1-0, S-1-5-32-545, S-1-5-6, S-1-2-1...}
Token              : 3052
AccessToken        : Microsoft.Win32.SafeHandles.SafeAccessTokenHandle
UserClaims         : {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: User Manager\ContainerAdministrator, http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid: S-1-5-93-2-1, http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid:
                     S-1-1-0, http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid: S-1-5-32-545...}
DeviceClaims       : {}
Claims             : {http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name: User Manager\ContainerAdministrator, http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid: S-1-5-93-2-1, http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid:
                     S-1-1-0, http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid: S-1-5-32-545...}
Actor              :
BootstrapContext   :
Label              :
NameClaimType      : http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
RoleClaimType      : http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid

PS C:\> (New-Object Security.Principal.WindowsPrincipal $user).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
True

So I've tried the following:

1. Run a build step in the container that sets the folder permissions to "Everyone - Full Access"

2. Run the script manually in the running container at startup that does the same

3. Connect to the container when running, and manually run the powershell to do the same

Each time, before attempting to generate the cipher file, the permissions look like this:

PS C:\> Get-ACL C:\bamboo-home\xml-data\configuration\ | fl

Path   : Microsoft.PowerShell.Core\FileSystem::C:\bamboo-home\xml-data\configuration\
Owner  : User Manager\ContainerAdministrator
Group  : User Manager\ContainerAdministrator
Access : Everyone Allow  FullControl
         NT AUTHORITY\SYSTEM Allow  FullControl
         BUILTIN\Administrators Allow  FullControl
         S-1-5-21-2465844383-291681238-1546083700-500 Allow  FullControl
Audit  :
Sddl   : O:S-1-5-93-2-1G:S-1-5-93-2-1D:AI(A;OICIID;FA;;;WD)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;S-1-5-21-2465844383-291681238-1546083700-500)

And the above error occurs after attempting the generation, and the permissions change to:

PS C:\> Get-ACL C:\bamboo-home\xml-data\configuration\ | fl

Path   : Microsoft.PowerShell.Core\FileSystem::C:\bamboo-home\xml-data\configuration\
Owner  : User Manager\ContainerAdministrator
Group  : User Manager\ContainerAdministrator
Access : Everyone Allow  FullControl
Audit  :
Sddl   : O:S-1-5-93-2-1G:S-1-5-93-2-1D:AI(A;OICI;FA;;;WD)

Why does the default account (presumably an Administrator named containeradministrator) lose access to this directory when it seems to indicate it has ownership? And why can't it create the file (or folder, for that matter) in the first place, since in both cases, "Everyone" should have full access?

Answer 1

I did not identify the issue between host/container permissions, but the way I brought up the container allowed the issue to happen. By changing my setup process, I was able to correct this.

Initial creation (that failed permissions on the created folder):

1. Create blank folder on host machine.
2. Link as volume with compose to container internal folder (all of C:\bamboo-home in this case). This is the folder that Bamboo will place all it's configuration/workspace stuff.
3. Setup product inside container, everything works except failure of the cipher folder. Didn't notice issue until this step.

New creation (that works properly):

1. Create blank folder on host machine.
2. Link as volume with compose to container internal folder (C:\empty, in this case). This does NOT link to C:\bamboo-home, which will be made internally in the running container as required.
3. Setup the product inside container. Once complete, copy all files from the container's folder to the new blank folder created. This way, the permissions are set in a consistent way inside the container itself, and the issues from before were mitigated.