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,
GRmeansGENERIC_READandGWmeansGENERIC_WRITE. - For file and named-pipe objects, generic rights have documented mappings.
- For a named pipe,
GENERIC_READmaps toFILE_READ_DATA,FILE_READ_ATTRIBUTES,FILE_READ_EA,SYNCHRONIZE, andREAD_CONTROL. - For a named pipe,
GENERIC_WRITEmaps toFILE_WRITE_DATA,FILE_APPEND_DATA,FILE_WRITE_ATTRIBUTES,FILE_WRITE_EA,SYNCHRONIZE, andREAD_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_READfor 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_WRITEfor 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.