GetKernelObjectSecurity support and ACE mask representation for a named pipe created with SDDL GRGW

Question

GetKernelObjectSecurity support and ACE mask representation for a named pipe created with SDDL GRGW

fengchun chen 0

Hello,

We are reviewing documented Windows behavior for a named pipe created with an explicit security descriptor. Could you clarify the following two points and, where available, provide authoritative Microsoft documentation references?

1. GetKernelObjectSecurity applicability

Is GetKernelObjectSecurity, when called on a server-side handle returned by CreateNamedPipeW with the required READ_CONTROL access, a supported operation for retrieving the named pipe's owner and DACL?

If so, what applicability or handle-access restrictions apply?

2. ACE mask representation for SDDL GRGW

When the named pipe is created using a security descriptor produced by ConvertStringSecurityDescriptorToSecurityDescriptorW from SDDL containing GRGW, what supported relationship exists between those generic ACE rights and the ACE mask subsequently returned through that security-descriptor read-back?

Are the generic bits retained, or are they mapped to named-pipe-specific rights? What documented mapping or representation guarantees apply?

Our purpose is to compare the actual ACE masks against independently established expected masks. We are not requesting alternative APIs or changes to Windows behavior.

Thank you.

0 comments

2 answers

Your answer

Answer 1

RLWA32 52,836

With respect to Question 1 refer to Low-level Security Descriptor Functions. The documentation does not include named pipes as objects for which GetKernelObjectSecurity should be used.

fengchun chen 0 Reputation points

2026-09-20T13:39:00+00:00

Thank you. That clarifies Question 1. Could you also clarify Question 2 regarding the documented ACE mask representation after creating the named pipe from SDDL containing GRGW — specifically whether read-back is documented to retain the generic bits or return mapped object-specific rights?

Answer 2

For point 1, the supported fact in the available documentation is that named pipes are securable objects with defined access rights, including READ_CONTROL, which is the right to read the security descriptor for the file or named pipe. The named-pipe security documentation also states that FILE_GENERIC_READ and FILE_GENERIC_WRITE each include reading the pipe’s DACL, and that ACCESS_SYSTEM_SECURITY is required if the SACL must be read or written. The provided documentation does not state GetKernelObjectSecurity applicability specifically for a CreateNamedPipeW server handle, so the supported conclusion is limited to this: reading the named pipe security descriptor requires appropriate access such as READ_CONTROL, and SACL access additionally requires ACCESS_SYSTEM_SECURITY.

For point 2, the documented relationship is:

In SDDL ACE strings, GR means GENERIC_READ and GW means GENERIC_WRITE.
For file and named-pipe objects, generic rights have documented mappings.
For a named pipe, GENERIC_READ maps to FILE_READ_DATA, FILE_READ_ATTRIBUTES, FILE_READ_EA, SYNCHRONIZE, and READ_CONTROL.
For a named pipe, GENERIC_WRITE maps to FILE_WRITE_DATA, FILE_APPEND_DATA, FILE_WRITE_ATTRIBUTES, FILE_WRITE_EA, SYNCHRONIZE, and READ_CONTROL.

So for an ACE expressed in SDDL as GRGW, the documented rights represented are the union of those mapped rights. The named-pipe-specific documentation further explains the semantic grouping:

FILE_GENERIC_READ for a named pipe combines the rights to read data from the pipe, read pipe attributes, read extended attributes, and read the pipe's DACL.
FILE_GENERIC_WRITE for a named pipe combines the rights to write data, append data, write pipe attributes, write extended attributes, and read the pipe's DACL.

An important documented caveat is that for named pipes, FILE_APPEND_DATA and FILE_CREATE_PIPE_INSTANCE have the same definition, so FILE_GENERIC_WRITE enables permission to create the pipe. To avoid that problem, the documentation recommends using individual rights instead of FILE_GENERIC_WRITE.

The available documentation supports the generic-to-object-specific mapping above. It does not provide a guarantee here about whether a later security-descriptor read-back must preserve the ACE mask as generic bits versus returning an object-specific expanded mask. Only the mapping itself is documented in the provided material.