[python-win32] Unexpected feature in win32security?

[Tim Golden]

I *think* this is a bug (or at least an unfortunate effect)
but I'll post here first for a sanity check.

I'm looking at Windows security: descriptors, ACLs, etc. The
conventional wisdom is that a DACL (or an SACL but less commonly)
can be one of three things within a security descriptor:

1) Not there
2) There but NULL
3) There and a (possibly empty) list of ACEs

When calling the GetSecurityDescriptorDacl Win32 API, the first
and second situations are distinguished by the lpbDaclPresent
parameter which receives 0 or 1. From that result, the pDacl
parameter is either meaningless or NULL/pointer to a list.

Within the win32security module, the GetSecurityDescriptorDacl
method of the PySECURITY_DESCRIPTOR object returns None in
both of the first two cases and I can't see any other way to
distinguish the cases without dropping down to ctypes or a
hand-built extension.

The offending code is in PySECURITY_DESCRIPTOR.cpp:

<snippet>
	// get Dacl from SD
	if (!::GetSecurityDescriptorDacl(psd, &bDaclPresent, &pdacl, &bDaclDefaulted))
		return PyWin_SetAPIError("GetSecurityDescriptorDacl");

	if (!bDaclPresent || pdacl == NULL)
	{
		Py_INCREF(Py_None);
		return Py_None;
	}

	return new PyACL(pdacl);

</snippet>

which returns None, as you see, in either case. The equivalent code
for SACL does the same thing.


I've not got an easy workaround. In general, it's very unlikely that
a DACL isn't present at all; and it's equally unlikely (I'm not sure
it's even meaningful) to have a NULL SACL. So I can fudge around things
a bit. But I'd prefer something more robust. However, it's difficult to
see what change to suggest without breaking the interface. The only
possibility I could come up with would be a separate pair of functions
whose only job would be to report the presence of the ACL in the SD.

Have I missed anything?

TJG