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
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
