Windows 10 - named pipe path

[lippertmarkus]

I've got Docker version 18.06.1-ce running and the named pipe is located at \\.\pipe\docker_engine instead of \\.\pipe\docker_engine_windows which leads to following error:

PS C:\Windows\system32> Import-Module dockeraccesshelper
PS C:\Windows\system32> Add-AccountToDockerAccess "JEML\lippertmarkus"
Ausnahme beim Aufrufen von "GetAccessControl" mit 0 Argument(en):  "\\.\pipe\docker_engine_windows"
In C:\Program Files\WindowsPowerShell\Modules\dockeraccesshelper\0.0.1\Add-AccountToDockerAccess.psm1:36 Zeichen:5
+     $dSec = $dInfo.GetAccessControl()
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DirectoryNotFoundException

Es ist nicht möglich, eine Methode für einen Ausdruck aufzurufen, der den NULL hat.
In C:\Program Files\WindowsPowerShell\Modules\dockeraccesshelper\0.0.1\Add-AccountToDockerAccess.psm1:38 Zeichen:5
+     $dSec.AddAccessRule($rule)
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

Ausnahme beim Aufrufen von "SetAccessControl" mit 1 Argument(en):  "Der Wert darf nicht NULL sein.
Parametername: directorySecurity"
In C:\Program Files\WindowsPowerShell\Modules\dockeraccesshelper\0.0.1\Add-AccountToDockerAccess.psm1:39 Zeichen:5
+     $dInfo.SetAccessControl($dSec)
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentNullException

Don't know if this has changed between the releases but I think it would be safe to check the existence of the pipe and maybe also autodetect the correct pipe path before setting the access rule. This way you could also handle errors that occur if the Docker daemon doesn't run and the pipe is therefore not present.

[tfenster]

Good point, I'll improve that. To understand the effect: is Docker running in Linux container mode?

[lippertmarkus]

Docker is running in Windows container mode (as LCOWs work simultaneously anyway). But I found out that when running the docker engine as a service - and not just the dockerd binary in the command line - then both pipes are available (but with different access controls):

PS C:\> $npipe = "\\.\pipe\docker_engine"
PS C:\> $npipe2 = "\\.\pipe\docker_engine_windows"

PS C:\> $dInfo = New-Object "System.IO.DirectoryInfo" -ArgumentList $npipe
PS C:\> $dInfo2 = New-Object "System.IO.DirectoryInfo" -ArgumentList $npipe2

PS C:\> $dInfo.GetAccessControl()

Path Owner              Access
---- -----              ------
     JEML\lippertmarkus NT-AUTORITÄT\SYSTEM Allow  FullControl...

PS C:\> $dInfo2.GetAccessControl()

PS C:\Windows\system32> $dInfo.GetAccessControl()

Path Owner                        Access
---- -----                        ------
     VORDEFINIERT\Administratoren NT-AUTORITÄT\SYSTEM Allow  FullControl...

Setting the access control only on the first one did work for me.

[tfenster]

@lippertmarkus should be fixed now. I first try to set the ACL on docker_engine_windows to match your case and the "standard" Win 10 case. Then I also do the same for docker_engine

[lippertmarkus]

@tfenster Thank you, this worked for me!
Unfortunately ACLs set on \\.\pipe\docker_engine aren't restored after a restart like the ACLs on \\.\pipe\docker_engine_windows which is only available when using the docker service which I can't use cause it's always eating up my whole RAM after a while (seems like a memory leak) - but that's another topic specific to me and doesn't belong here.