[python-win32] Unexpected feature in win32security?

[Tim Golden]

Roger Upole wrote:

Thanks very much for responding to this, Roger.

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

> In practice, cases 1 and 2 are functionally identical . Once a security 
> descriptor has
> been applied to an object, the SE_DACL_PRESENT flag is always set.  If for
> some reason you really need this info, you can call 
> GetSecurityDescriptorControl
> and check for presence of the SE_DACL_PRESENT flag.

That's the key bit I missed. My use case is a bit
abstruse, as I'm writing some wrapper code to
allow slightly easier access to the security stuff
and my unit tests are failing. Therefore what I'm
doing is a bit artificial but (to me) necessary :)

> It's quite common for either of these to be NULL.
> Most often files don't specify their own security, and just inherit from
> the parent directory.  

That's clearly the case, but I thought that this meant
that their DACL was an effective copy of the parent
DACL, not a NULL, eg the following code gives me a PyACL
object, not None:

<code>
from win32security import *

#
# Create file with no special security, effectively
# inheriting from its parent
#
open ("c:/temp/blah.txt", "w").close ()
sd = GetNamedSecurityInfo (
  "c:/temp/blah.txt", 
  SE_FILE_OBJECT, 
  DACL_SECURITY_INFORMATION
)
print sd.GetSecurityDescriptorDacl ()

</code>

Despite my question here, I don't recall ever actually
coming across a NULL DACL on a file -- which is where
most of my activity is -- but they may be more common
on kernel objects or registry keys or whatever.


> SACL's are often NULL also, although they
> don't show a difference in behaviour between NULL and empty as
> DACL's do.

That I can believe; it's only, as I say, for testing reasons
that I necessarily care. In any case, your pointer to the 
descriptor control has effectively answered my main question,
so thanks very much.

TJG