Why does Windows process all NTFS child objects when changing a parent’s ACL?
up vote
8
down vote
favorite
Why does Windows process all NTFS child objects when changing a parent’s ACL?
I would expect this behavior if I had checked the “Replace all child object permissions...” box, but even when that box is left unchecked, Windows will process all the children.
windows ntfs
asked Nov 19 at 3:53
Corey
81292748
add a comment |
up vote
8
down vote
favorite
Why does Windows process all NTFS child objects when changing a parent’s ACL?
I would expect this behavior if I had checked the “Replace all child object permissions...” box, but even when that box is left unchecked, Windows will process all the children.
windows ntfs
asked Nov 19 at 3:53
Corey
81292748
@Ben It is not done by the shell, because the cascade of inherited permissions must be replicated to all child objects with inherit enabled, so it has to be done even when calling the Windows API directly. FYI: Permissions are replicated for performance reasons.
– Andreas
Nov 19 at 21:43
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
Why does Windows process all NTFS child objects when changing a parent’s ACL?
I would expect this behavior if I had checked the “Replace all child object permissions...” box, but even when that box is left unchecked, Windows will process all the children.
windows ntfs
asked Nov 19 at 3:53
Corey
81292748
Why does Windows process all NTFS child objects when changing a parent’s ACL?
I would expect this behavior if I had checked the “Replace all child object permissions...” box, but even when that box is left unchecked, Windows will process all the children.
windows ntfs
windows ntfs
asked Nov 19 at 3:53
Corey
81292748
asked Nov 19 at 3:53
Corey
81292748
asked Nov 19 at 3:53
Corey
81292748
asked Nov 19 at 3:53
Corey
81292748
asked Nov 19 at 3:53
Corey
81292748
81292748
@Ben It is not done by the shell, because the cascade of inherited permissions must be replicated to all child objects with inherit enabled, so it has to be done even when calling the Windows API directly. FYI: Permissions are replicated for performance reasons.
– Andreas
Nov 19 at 21:43
add a comment |
@Ben It is not done by the shell, because the cascade of inherited permissions must be replicated to all child objects with inherit enabled, so it has to be done even when calling the Windows API directly. FYI: Permissions are replicated for performance reasons.
– Andreas
Nov 19 at 21:43
@Ben It is not done by the shell, because the cascade of inherited permissions must be replicated to all child objects with inherit enabled, so it has to be done even when calling the Windows API directly. FYI: Permissions are replicated for performance reasons.
– Andreas
Nov 19 at 21:43
@Ben It is not done by the shell, because the cascade of inherited permissions must be replicated to all child objects with inherit enabled, so it has to be done even when calling the Windows API directly. FYI: Permissions are replicated for performance reasons.
– Andreas
Nov 19 at 21:43
add a comment |
3 Answers
3
active
oldest
votes
up vote
11
down vote
Any child object that is configured to inherit it’s permissions from the parent object will need to be processed. Explicitly defined permissions on the child objects are not affected.
The option, “Replace permissions on all child objects,” will not only propagate the permissions to all child objects but it will also remove and replace any explicitly defined permissions on all child objects.
answered Nov 19 at 4:52
Appleoddity
1,9241315
add a comment |
up vote
6
down vote
In Windows file permissions are not dynamically inherited. That is, when an attempt is made to open a file Windows only looks at the ACL of that file and not at the ACLs of the directories in the tree containing the file. That means when you change the ACL of a directory Windows has to immediately update the permissions of all files and subdirectories within the affected directory.
In Windows the inherit setting in an ACL does not indicate any form of dynamic inheritance. It is just a flag to indicate that when a parent directory's ACL is modified all files and subdirectories in the tree that have the inherit flag set must also be updated.
Those of us old enough to remember Novell NetWare will remember this was one of the big differences from NetWare because in NetWare inheritance of permissions is (was?) dynamic. There was much debate at the time about which approach was better, though history has rendered the issue moot. Dynamic ACLs require the OS to check the ACLs of every parent directory at the time an attempt is made to open the file, but changing ACLs is quick. In Windows opening file requires only a single ACL to be checked, but as you've found it means changing a directory ACL can be slow.
answered Nov 19 at 12:13
John Rennie
7,33311830
1
This makes perfect sense. ACLs are read a lot more than they're written, so it makes sense to cache the "inherited value" for faster read access, at the cost of more complexity in the rarer write use case.
– Alexander
Nov 19 at 20:47
@Alexander: What I don't understand is why this complexity has to be exposed to the end user. Why not lie and tell the end user "it's dynamic" but cache things internally?
– Kevin
Nov 20 at 4:34
@Kevin - because it can take some time to propagate permissions and in that time period you enforcement of permissions might not happen as you expect?
– davidbak
Nov 20 at 4:44
add a comment |
up vote
4
down vote
By default, child folders inherit permissions from the parent folder. Assuming the default scope when you're adding/modifying permissions on the parent folder (this folder, subfolders and files) then all child folders will be updated to reflect the permissions change at the parent.
The checkbox you're referring to is a "one time" operation that will remove all explicitly defined permissions on all child folders and replace them with inheritable permissions from the parent and will re-enable permissions inheritance on the child folders.
answered Nov 19 at 4:50
joeqwerty
94.5k462147
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
11
down vote
Any child object that is configured to inherit it’s permissions from the parent object will need to be processed. Explicitly defined permissions on the child objects are not affected.
The option, “Replace permissions on all child objects,” will not only propagate the permissions to all child objects but it will also remove and replace any explicitly defined permissions on all child objects.
answered Nov 19 at 4:52
Appleoddity
1,9241315
add a comment |
up vote
11
down vote
Any child object that is configured to inherit it’s permissions from the parent object will need to be processed. Explicitly defined permissions on the child objects are not affected.
The option, “Replace permissions on all child objects,” will not only propagate the permissions to all child objects but it will also remove and replace any explicitly defined permissions on all child objects.
answered Nov 19 at 4:52
Appleoddity
1,9241315
add a comment |
up vote
11
down vote
up vote
11
down vote
Any child object that is configured to inherit it’s permissions from the parent object will need to be processed. Explicitly defined permissions on the child objects are not affected.
The option, “Replace permissions on all child objects,” will not only propagate the permissions to all child objects but it will also remove and replace any explicitly defined permissions on all child objects.
answered Nov 19 at 4:52
Appleoddity
1,9241315
Any child object that is configured to inherit it’s permissions from the parent object will need to be processed. Explicitly defined permissions on the child objects are not affected.
The option, “Replace permissions on all child objects,” will not only propagate the permissions to all child objects but it will also remove and replace any explicitly defined permissions on all child objects.
answered Nov 19 at 4:52
Appleoddity
1,9241315
answered Nov 19 at 4:52
Appleoddity
1,9241315
answered Nov 19 at 4:52
Appleoddity
1,9241315
answered Nov 19 at 4:52
Appleoddity
1,9241315
1,9241315
add a comment |
add a comment |
up vote
6
down vote
In Windows file permissions are not dynamically inherited. That is, when an attempt is made to open a file Windows only looks at the ACL of that file and not at the ACLs of the directories in the tree containing the file. That means when you change the ACL of a directory Windows has to immediately update the permissions of all files and subdirectories within the affected directory.
In Windows the inherit setting in an ACL does not indicate any form of dynamic inheritance. It is just a flag to indicate that when a parent directory's ACL is modified all files and subdirectories in the tree that have the inherit flag set must also be updated.
Those of us old enough to remember Novell NetWare will remember this was one of the big differences from NetWare because in NetWare inheritance of permissions is (was?) dynamic. There was much debate at the time about which approach was better, though history has rendered the issue moot. Dynamic ACLs require the OS to check the ACLs of every parent directory at the time an attempt is made to open the file, but changing ACLs is quick. In Windows opening file requires only a single ACL to be checked, but as you've found it means changing a directory ACL can be slow.
answered Nov 19 at 12:13
John Rennie
7,33311830
1
This makes perfect sense. ACLs are read a lot more than they're written, so it makes sense to cache the "inherited value" for faster read access, at the cost of more complexity in the rarer write use case.
– Alexander
Nov 19 at 20:47
@Alexander: What I don't understand is why this complexity has to be exposed to the end user. Why not lie and tell the end user "it's dynamic" but cache things internally?
– Kevin
Nov 20 at 4:34
@Kevin - because it can take some time to propagate permissions and in that time period you enforcement of permissions might not happen as you expect?
– davidbak
Nov 20 at 4:44
add a comment |
up vote
6
down vote
In Windows file permissions are not dynamically inherited. That is, when an attempt is made to open a file Windows only looks at the ACL of that file and not at the ACLs of the directories in the tree containing the file. That means when you change the ACL of a directory Windows has to immediately update the permissions of all files and subdirectories within the affected directory.
In Windows the inherit setting in an ACL does not indicate any form of dynamic inheritance. It is just a flag to indicate that when a parent directory's ACL is modified all files and subdirectories in the tree that have the inherit flag set must also be updated.
Those of us old enough to remember Novell NetWare will remember this was one of the big differences from NetWare because in NetWare inheritance of permissions is (was?) dynamic. There was much debate at the time about which approach was better, though history has rendered the issue moot. Dynamic ACLs require the OS to check the ACLs of every parent directory at the time an attempt is made to open the file, but changing ACLs is quick. In Windows opening file requires only a single ACL to be checked, but as you've found it means changing a directory ACL can be slow.
answered Nov 19 at 12:13
John Rennie
7,33311830
1
This makes perfect sense. ACLs are read a lot more than they're written, so it makes sense to cache the "inherited value" for faster read access, at the cost of more complexity in the rarer write use case.
– Alexander
Nov 19 at 20:47
@Alexander: What I don't understand is why this complexity has to be exposed to the end user. Why not lie and tell the end user "it's dynamic" but cache things internally?
– Kevin
Nov 20 at 4:34
@Kevin - because it can take some time to propagate permissions and in that time period you enforcement of permissions might not happen as you expect?
– davidbak
Nov 20 at 4:44
add a comment |
up vote
6
down vote
up vote
6
down vote
In Windows file permissions are not dynamically inherited. That is, when an attempt is made to open a file Windows only looks at the ACL of that file and not at the ACLs of the directories in the tree containing the file. That means when you change the ACL of a directory Windows has to immediately update the permissions of all files and subdirectories within the affected directory.
In Windows the inherit setting in an ACL does not indicate any form of dynamic inheritance. It is just a flag to indicate that when a parent directory's ACL is modified all files and subdirectories in the tree that have the inherit flag set must also be updated.
Those of us old enough to remember Novell NetWare will remember this was one of the big differences from NetWare because in NetWare inheritance of permissions is (was?) dynamic. There was much debate at the time about which approach was better, though history has rendered the issue moot. Dynamic ACLs require the OS to check the ACLs of every parent directory at the time an attempt is made to open the file, but changing ACLs is quick. In Windows opening file requires only a single ACL to be checked, but as you've found it means changing a directory ACL can be slow.
answered Nov 19 at 12:13
John Rennie
7,33311830
In Windows file permissions are not dynamically inherited. That is, when an attempt is made to open a file Windows only looks at the ACL of that file and not at the ACLs of the directories in the tree containing the file. That means when you change the ACL of a directory Windows has to immediately update the permissions of all files and subdirectories within the affected directory.
In Windows the inherit setting in an ACL does not indicate any form of dynamic inheritance. It is just a flag to indicate that when a parent directory's ACL is modified all files and subdirectories in the tree that have the inherit flag set must also be updated.
Those of us old enough to remember Novell NetWare will remember this was one of the big differences from NetWare because in NetWare inheritance of permissions is (was?) dynamic. There was much debate at the time about which approach was better, though history has rendered the issue moot. Dynamic ACLs require the OS to check the ACLs of every parent directory at the time an attempt is made to open the file, but changing ACLs is quick. In Windows opening file requires only a single ACL to be checked, but as you've found it means changing a directory ACL can be slow.
answered Nov 19 at 12:13
John Rennie
7,33311830
answered Nov 19 at 12:13
John Rennie
7,33311830
answered Nov 19 at 12:13
John Rennie
7,33311830
answered Nov 19 at 12:13
John Rennie
7,33311830
7,33311830
1
This makes perfect sense. ACLs are read a lot more than they're written, so it makes sense to cache the "inherited value" for faster read access, at the cost of more complexity in the rarer write use case.
– Alexander
Nov 19 at 20:47
@Alexander: What I don't understand is why this complexity has to be exposed to the end user. Why not lie and tell the end user "it's dynamic" but cache things internally?
– Kevin
Nov 20 at 4:34
@Kevin - because it can take some time to propagate permissions and in that time period you enforcement of permissions might not happen as you expect?
– davidbak
Nov 20 at 4:44
add a comment |
1
This makes perfect sense. ACLs are read a lot more than they're written, so it makes sense to cache the "inherited value" for faster read access, at the cost of more complexity in the rarer write use case.
– Alexander
Nov 19 at 20:47
@Alexander: What I don't understand is why this complexity has to be exposed to the end user. Why not lie and tell the end user "it's dynamic" but cache things internally?
– Kevin
Nov 20 at 4:34
@Kevin - because it can take some time to propagate permissions and in that time period you enforcement of permissions might not happen as you expect?
– davidbak
Nov 20 at 4:44
1
1
This makes perfect sense. ACLs are read a lot more than they're written, so it makes sense to cache the "inherited value" for faster read access, at the cost of more complexity in the rarer write use case.
– Alexander
Nov 19 at 20:47
This makes perfect sense. ACLs are read a lot more than they're written, so it makes sense to cache the "inherited value" for faster read access, at the cost of more complexity in the rarer write use case.
– Alexander
Nov 19 at 20:47
@Alexander: What I don't understand is why this complexity has to be exposed to the end user. Why not lie and tell the end user "it's dynamic" but cache things internally?
– Kevin
Nov 20 at 4:34
@Alexander: What I don't understand is why this complexity has to be exposed to the end user. Why not lie and tell the end user "it's dynamic" but cache things internally?
– Kevin
Nov 20 at 4:34
@Kevin - because it can take some time to propagate permissions and in that time period you enforcement of permissions might not happen as you expect?
– davidbak
Nov 20 at 4:44
@Kevin - because it can take some time to propagate permissions and in that time period you enforcement of permissions might not happen as you expect?
– davidbak
Nov 20 at 4:44
add a comment |
up vote
4
down vote
By default, child folders inherit permissions from the parent folder. Assuming the default scope when you're adding/modifying permissions on the parent folder (this folder, subfolders and files) then all child folders will be updated to reflect the permissions change at the parent.
The checkbox you're referring to is a "one time" operation that will remove all explicitly defined permissions on all child folders and replace them with inheritable permissions from the parent and will re-enable permissions inheritance on the child folders.
answered Nov 19 at 4:50
joeqwerty
94.5k462147
add a comment |
up vote
4
down vote
By default, child folders inherit permissions from the parent folder. Assuming the default scope when you're adding/modifying permissions on the parent folder (this folder, subfolders and files) then all child folders will be updated to reflect the permissions change at the parent.
The checkbox you're referring to is a "one time" operation that will remove all explicitly defined permissions on all child folders and replace them with inheritable permissions from the parent and will re-enable permissions inheritance on the child folders.
answered Nov 19 at 4:50
joeqwerty
94.5k462147
add a comment |
up vote
4
down vote
up vote
4
down vote
By default, child folders inherit permissions from the parent folder. Assuming the default scope when you're adding/modifying permissions on the parent folder (this folder, subfolders and files) then all child folders will be updated to reflect the permissions change at the parent.
The checkbox you're referring to is a "one time" operation that will remove all explicitly defined permissions on all child folders and replace them with inheritable permissions from the parent and will re-enable permissions inheritance on the child folders.
answered Nov 19 at 4:50
joeqwerty
94.5k462147
By default, child folders inherit permissions from the parent folder. Assuming the default scope when you're adding/modifying permissions on the parent folder (this folder, subfolders and files) then all child folders will be updated to reflect the permissions change at the parent.
The checkbox you're referring to is a "one time" operation that will remove all explicitly defined permissions on all child folders and replace them with inheritable permissions from the parent and will re-enable permissions inheritance on the child folders.
answered Nov 19 at 4:50
joeqwerty
94.5k462147
answered Nov 19 at 4:50
joeqwerty
94.5k462147
answered Nov 19 at 4:50
joeqwerty
94.5k462147
answered Nov 19 at 4:50
joeqwerty
94.5k462147
94.5k462147
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f940636%2fwhy-does-windows-process-all-ntfs-child-objects-when-changing-a-parent-s-acl%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
@Ben It is not done by the shell, because the cascade of inherited permissions must be replicated to all child objects with inherit enabled, so it has to be done even when calling the Windows API directly. FYI: Permissions are replicated for performance reasons.
– Andreas
Nov 19 at 21:43