Re: Removal of inherited aces
- From: "Paul Baker [MVP, Windows Desktop Experience]" <paulrichardbaker@xxxxxxxxxxxxxxxx>
- Date: Fri, 22 May 2009 16:37:18 -0400
I don't really know what you're asking.
I said that it is possible that at one time they were inherited but someone
unchecked "Inherit from parent...". This is equivalent, I think, to calling
SetNamedSecurityInfo flag PROTECTED_DACL_SECURITY_INFORMATION. So someone
did - you!
So you are in effect choosing not to inherit the ACEs and then wondering why
when you delete them, the effect is not inherited.
You can specify that an ACE applies to "This folder only", etc. using the
Edit button if that helps.
Paul
-
"JRB" <john@xxxxxxxxxxxxxxx> wrote in message
news:07904832-de33-4d57-be99-3e9118e8e1b8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Paul
Thanks for your response. I'm working with a directory on an NTFS
volume. If I grant user X rights to directory A, then subdirectories B
and C have inherited ACLs automatically added. If I then remove the
ACE for X, the inherited ACEs on B and C remain in place.
But I have made some progress on this. The culprit is the
SetNamedSecurityInfo flag PROTECTED_DACL_SECURITY_INFORMATION. I'd
been using this to prevent Windows doing any unwanted fiddling
(specifically adding an inherited ACE for the directory owner) with
the DACL when it was set, without fully understanding the
consequences. Still it is inconsistent that this flag appears to allow
inherited ACEs to be added to child objects but prevents the the
removal of those ACEs.
Is there any other way to set a DACL exactly as specified other than
by specifying the PROTECTED_DACL_SECURITY_INFORMATION flag? I'm
working on a general purpose program for modifying file system dacls,
and want to ensure that the only changes to the dacl are those the
program has been requested to make.
Thanks, John
On May 22, 3:49 am, "Paul Baker [MVP, Windows Desktop Experience]"
<paulrichardba...@xxxxxxxxxxxxxxxx> wrote:
What type of object is this? Not that I really think it matters for
Windows
Server 2003 R2.
Are these ACEs really inherited? Look at the advanced security settings at
"Inherited From". It is possible that at one time they were inherited but
someone unchecked "Inherit from parent..." and chose to copy them.
Paul
"JRB" <j...@xxxxxxxxxxxxxxx> wrote in message
news:08127ded-dadf-4ff6-a918-5aa21a6c3fbd@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
When I add an inheritable ACE to a directory via SetNamedSecurityInfo,
the ACE is automatically propogated to child objects as an inherited
ACE. However, when I then remove the inheritable ACE via
SetNamedSecurityInfo, the inherited ACE entries of child objects
remain in place. This is Windows server 2003 R2. Is there an API (or
flags setting for SetNamedSecurityInfo) which will automatically
remove the inherited ACES upon removal of the ACE from which they
derive, or is it up to the application to handle that.
Thanks, John- Hide quoted text -
- Show quoted text -
.
- Follow-Ups:
- Re: Removal of inherited aces
- From: JRB
- Re: Removal of inherited aces
- References:
- Removal of inherited aces
- From: JRB
- Re: Removal of inherited aces
- From: Paul Baker [MVP, Windows Desktop Experience]
- Re: Removal of inherited aces
- From: JRB
- Removal of inherited aces
- Prev by Date: Bug in CryptAcquireCertificatePrivateKey?
- Next by Date: ActiveX Control is signed but IE is still blocking it - Why?
- Previous by thread: Re: Removal of inherited aces
- Next by thread: Re: Removal of inherited aces
- Index(es):