I'm trying to create a named pipe between two Windows processes. The server process runs under a normal account, in a UI session. The client process runs in an unknown security context, apparently rather restricted.
Initially I called
pipe = CreateNamedPipeA(MY_PIPE_NAME, PIPE_ACCESS_DUPLEX,
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE, maxClients,
pipeChunkSize, pipeChunkSize, 0, nullptr);
I.e. leave pass no SECURITY_ATTRIBUTES
. Usually, this works - no security means no security. Apparently, this is no longer the case for named pips. The caller tried
CreateFileA(MY_PIPE_NAME, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
and got back a GetLastError=5
, access denied. Testing showed that this was due to a security failure; the exact same line would succeed if the client executable was run from a test environment in the same UI session as the server.
The logical solution would be to set the DACL to SECURITY_WORLD_SID_AUTHORITY, KEY_ALL_ACCESS
(S-1-1-0) in the SECURITY_ATTRIBUTES
used for CreateNamedPipeA
. This didn't fix the problem.
The only security downgrade left from "everybody can do everything" would be "no security whatsoever". What do I have to do in CreateNamedPipe
so that CreateFileA
never fails with an Access Denied?
Security is pretty irrelevant here. PIPE_TYPE_MESSAGE
and pipeChunkSize
already mean that the server is safe against buffer overflows by rogue clients.