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