-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quick review: ACE = Access Control Entry - many of these on a file;
ACL = List of Access Control Entries - only 1 of these on a file.
Explorer sets ACEs by adding them to the ACL.
I just did a quick test and my results confirm what I already
believed about how ACEs are set.
Explorer propogates inheritable permissions to subdirectories.The OS
/ File System does not take care of this.
I used explorer to create a directory and 2 subdirectories within
this first directory.
I made sure Dir1 was set to inherit acls from it’s parent. I made
sure Dir2 was set to NOT inherit ACEs. I then changed the ACL with
Explorer on the parent and verified that Dir1 got the new ACEs that I
added to the ACL and Dir2 did not.
I then repeated this experiment with CACLS - the NT Command line
utility that sets ACLs. I observered that when I set the parent’s ACL
with CACLS the ACE was not inherited by either of the subdirectories.
- From this I conclude that the File System was not involved in the
inheritence of ACEs, it was the application that did it (or actually,
did not do it).
I also noticed in CACLS help information that there’s a switch (/T)
which allows you to set whether you want to propogate the change
you’re making to the parent to all subdirectories of the parent too.
I repeated the experiment yet again, this time invoking /T.
This switch only sort-of works. While it does propogate the changes
you make, it does NOT observe the Inheritable aspect of the ACE. Dir2
which was set to NOT inherit ACEs, inherited it anyway, and the
“Inherit” property on the subdirectory itself was re-enabled so that
future changes would also be inherited from the parent. I believe
that this is poor CACLS behavior, but is a separate discussion. In
any case, the file system does not appear to be the entity
responsible for assigning inheritable ACEs.
It’s my understanding that when an ACE is inherited from a parent, a
copy of the ACE is stored with the file or subdirectory in the file’s
ACL. This ACE will have a special bit (INHERITED_ACE) turned on which
tells any application that may be interested that the ACE is an
inherited ACE from the parent. Notice what this means: when the OS
does an Access Check for the file, all it needs to do is go through
the list of ACES on the subdirectory. It does NOT need to check the
parent’s ACL and figure out whether there are any ACEs there that
apply to the subdirectory. Everything the OS needs to determine
access is in the subdirectory’s ACL.
BTW, Explorer must be checking the INHERITED_ACE bit for each ACE
when the subdirectory’s ACL is changed, because when you clear this
bit from the directory’s properties (by Unchecking “Allow Inheritable
permissions from parent to propogate to this object”) Explorer asks
you what you want to do with the current inherited ACEs: 1) copy them
from the parent, or 2) remove them from the ACL. When Explorer’s all
done with this operation, no ACEs in the subdirectory’s ACL should
have the INHERITED_ACE bit set. Does that make sense?
There’s a pretty good discussion of ACL inheritence in “Programming
Windows Security” by Keith Brown (Addison Wesley). Chapter 6
describes ACL inheritance in NT4 and compares it to inheritence in
W2K. Recommended reading.
ERX
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@yahoo.com Sent: Wednesday, October 03, 2001 10:31 AM
To: File Systems Developers
Subject: [ntfsd] RE: Question regarding propagation of ACL
Is this behavior (inherite ACL in subdirectory) the result of the
service that updates the ACL or is it done by NTFS proper?
For example, when I change the ACL through windows explorer property
security tab, is the explorer that propagates the ACL to the
subdirectories, or it’s NTFS doing the actual propagation?
Thanks,
Go-Tze
You are currently subscribed to ntfsd as: xxxxx@spinnakernet.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use http:
iQA/AwUBO7tS+53C8+NECRD+EQJngwCeLDL/2rrLs0o+dwswkT4YiFHLQEoAnjXd
TjloR3DEJvZD0qQplV6UHwbD
=oZV1
-----END PGP SIGNATURE-----
—
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com</http:>