|
Home > Archive > 70-210 > June 2001 > NTFS Permissions *Puzzled*
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
NTFS Permissions *Puzzled*
|
|
|
| Hi everyone,
I'm studying for my 70-210 exam and I've got bunch of questions so I hope somebody will be kind enough to read my post, try out some of the things I've noticed and help me. I'd really appreciate any feedback.
Well for this post I'll just start off by asking about NTFS permissions. I'm pretty confident I know enough about them but there is something that has been bothering me for awhile and I thought I should clear my conscience by asking other people.
Scenario:
Root is set as EVERYONE - FULL CONTROL (usually any new formatted drive is automatically configured this way)
or a folder anywhere is created and set with EVERYONE - FULL CONTROL
then a new folder is created inside that folder and the permissions are not allowed to be inherited to propagate to that new folder and I remove all permissions.
I add a user with only read & execute, list folder contents, read permissions.
Log out and login as that user. Go to that folder and select delete. I am able to delete the folder.
Why???
I'm going crazy. I suppose this is some quirk by design but can somebody explain to me why?
Thank you. | |
| dentonb2000 2001-06-03, 6:14 am |
| Tomo,
After trying as you did and receiving the same results, I went one step further by denying everyone the delete permission. Guess what, they user could still delete that directory! I then created a subdirectory within "Program Files" with the same exact permissions with the execption of not applying the delete permission; it worked as it should, the user was not able to delete the folder.
My conslusion: if by accident a user were to deny delete of the root folder, then they system would not be capable of recovery. If the administrator had to boot to system console to replace (to replace you must be able to delete) missing or corrupted boot files and were denied that access, then the system would be lost. As far as I can tell, you cannot deny delete on any root folder.
Hope this helps.
Denton | |
|
| Hi Denton,
Thank you for trying it out. I was afraid nobody would bother since it sounded quite ludricrous.
quote:
Originally posted by dentonb2000
Tomo,
After trying as you did and receiving the same results, I went one step further by denying everyone the delete permission. Guess what, they user could still delete that directory!
Yes, I noticed the exact same thing. If a file or subfolder is created here by someone who has the rights (admin) and the permissions are set to propagate, then the funny thing is, that new file or subfolder is not deletable by that restricted user, thus, not allowing the original folder from being deleted. I believe this is similar to what you tried by creating a folder in the "Program Files" dir.
quote:
I then created a subdirectory within "Program Files" with the same exact permissions with the execption of not applying the delete permission; it worked as it should, the user was not able to delete the folder.
Yes, I got the exact same results.
quote:
My conslusion: if by accident a user were to deny delete of the root folder, then they system would not be capable of recovery. If the administrator had to boot to system console to replace (to replace you must be able to delete) missing or corrupted boot files and were denied that access, then the system would be lost. As far as I can tell, you cannot deny delete on any root folder.
I see your point but this happens on any folder that is created anywhere on an NTFS formatted volume with full control permissions. Any directly below empty subfolders with non-delete permissions (can include but must all be specifically set files/subfolders with delete permissions) are still deletable even with the mother folder set with delete permissions denied.
I'm pretty sure this isn't important when I write the exam but I just can't understand why Microsoft has it designed this way, and furthermore not one MCSE study guide I have looked at mentions this.
I've even seen practice questions involving something related to this and I obviously had to disagree with all the answer choices. The question involved creating 3 home folders for various departments and giving the managers of each department enough control to fully manage the folders but without the power to delete the folders themselves. The question asked what permissions would you need to set. The answer was change permissions special access.
This answer has two flaws in my opinion. If a user can change the permissions, can't they just give themselves full control regardless of not originally having the take ownership right and doing whatever they pleased? On my computer I sure am.
Also, if the user was given the change permissions right, he could set all of the files and subfolders with the delete right, and then be able to delete the mother folder with all its contents if it was situated in a folder with full control permissions even if the folder itself had strict deny delete permissions set and once again prove that the answer to the question is flawed. | |
| dentonb2000 2001-06-03, 2:14 pm |
| At this point I am dumbfounded. | |
|
| Tomo,
What you are experiencing is a special permission that is included with "Full Control" (FC. When a directory is given FC it is also given the permission to delete its children even if there is no delete permission on the child. This hidden permission can be considered an exception to other permissions in that the permission is applied to the parent object, not the object itself.
I think this special behavior was included in NT to comply with POSIX.
Terje | |
|
| quote:
Originally posted by Terje
Tomo,
What you are experiencing is a special permission that is included with "Full Control" (FC. When a directory is given FC it is also given the permission to delete its children even if there is no delete permission on the child. This hidden permission can be considered an exception to other permissions in that the permission is applied to the parent object, not the object itself.
I think this special behavior was included in NT to comply with POSIX.
Terje
Hello Terje,
Thank you for replying to my post.
In my original post, I pointed out that this issue manifests itself when a parent folder is originally created in a "FC" container, and "Allow inheritable permissions from parent to propagate to this object" is unchecked, REMOVE is selected, and very limited permissions are set, permissions that automatically don't include any DELETE permissions. I've checked the special permissions and no DELETE related permissions are allowed. Yet the user will still able to delete the folder.
Thank you,
Jiro | |
|
| quote:
Originally posted by Tomo
I've checked the special permissions and no DELETE related permissions are allowed. Yet the user will still able to delete the folder.
Yes, that's right. That is why I called this an exception to the way permissions normally work in NT/2000. Unlike other permissions it is applied to another object than it affects.
If you are running 2000 now go to the parent folder. Check its special permissions. You will find the Delete subfolders and files permission. Uncheck it and now try to delete your subfolder/file (which still has no delete permission).
In NT there is no checkbox where you could uncheck this permission, but you can still disable it. Instead of giving the parent folder FC you give it special permission but check all the boxes. This is the same as giving FC except that the permission to delete children is no longer there.
I would not be surprised if this is on the exam (which I have not taken and therefore is not breaking any NDA).
Terje | |
|
| Hello Terje,
Please try out what I have explained in my original post.
I'll try to make the following clear as possible.
Create a folder in "C:\"
If you haven't changed anything prior to doing this, the new folder which you have just created should have "Everyone - FC" because it should automatically inherit that from its parent, "C:\".
Now, to remove "Everyone", you must deselect "Allow inheritable permissions from parent to propagate to this object" and please select "Remove", not "Copy". Then add any user you like and give them "Read" only permissions. If you want to check, check the special permissions or even deny the delete permissions, go ahead. Make it "delete" proof.
Now log off and logon as that user with the "read" only permissions. Go to "C:\" and delete or attempt to delete the folder. | |
|
| quote:
Originally posted by Tomo
I'll try to make the following clear as possible.
You have been perfectly clear from the beginning. I am sorry that I haven't.
quote:
Make it "delete" proof.
To make it "delete proof" it is not sufficient to remove delete permissions from the folder (or file) itself. You must also make sure that the parent folder does not have the special permission "delete subfolders and files". The parent folder in your example is not the new folder but the root folder (C:\). "delete subfolders and files" is part of FC.
Hope I made myself clearer now.
Onto something different. To experiment with permissions you do not really need that extra user. As the owner of an object (file or folder) you do not have any extra permissions to it except the permission to change permissions. E.g. you could remove all your own permissions to an object and see what you can do. Luckily you can still change the permissions back to something usefull.
Terje | |
|
| Hi Terje!
Thank you for clarifying, I now understand what you are saying.
Terje, even though what you say is completely clear to me, why don't any of the MCSE books I've looked at point this out? All I see everywhere is "File level protection", but I believe that is misleading and all of the books including Microsoft is misleading in that they only point out that you need to set permissions on individual files/folders without needing to worry about it's parent.
You are right about not needing to log on as another user, I just used that to keep things a little simple in explaining.
Sorry to bother you further, but what other permissions are being inherited from the parent? I'm really confused because unchecking "Allow inheritable permissions from parent to propagate to this object" and you telling me that it STILL is inheriting the delete permissions from its parent just boggles my mind. It just throws off everything I've learned and thought I understand... | |
|
| quote:
Originally posted by Tomo
Terje, even though what you say is completely clear to me, why don't any of the MCSE books I've looked at point this out?
I really don't know. They should, as this is indeed a significant feature of the NTFS permission system. I havn't seen any study guide for w2k yet. The online help (which is a much better resource in w2k than in any previous MS OS) explains this well enough.
quote:
All I see everywhere is "File level protection", but I believe that is misleading and all of the books including Microsoft is misleading in that they only point out that you need to set permissions on individual files/folders without needing to worry about it's parent.
Since this one is an exception to the general way permissions work in NTFS I feel the books should be carefull about mentioning it.
quote:
...but what other permissions are being inherited from the parent? I'm really confused because unchecking "Allow inheritable permissions from parent to propagate to this object" and you telling me that it STILL is inheriting the delete permissions from its parent just boggles my mind. It just throws off everything I've learned and thought I understand...
Do not confuse this with inheritance, because it isn't.
Inheritance means that in the absence of an explisit permission given to an object, the object has the same permission as the parent object. From then on untill you change it, the inherited permission has the same effect as if it was given explistly to the object. Inheritance can be switched on or off.
The delete subfolders and files special permission is different from other permissions in that you give it to one object, but it has consequences for another. You can turn on or off the permission, but unlike inheritance you can not override the effect on the child in the child itself. Neither can you disable its effect on the child as you can disable inheritance.
Of course(?) this special permission can be inherited (or not) from a folder to its subfolder in the usual way. In that respect the permission is quite ordinary. But still, the effect of the permission is on the folders content, not the folder itself.
I won't disagree that this is confusing, but it is the way NTFS works, and is intended to work.
As a sidenote: W2k is a significant improvment over NT in the way this permission now actually has a tick box where you can turn it on or off and see what you are doing. In NT you would have to know how to indirectly enable or disable it (described in earlier post).
Terje | |
| OmnipotentOne 2001-06-08, 2:39 am |
| ok this is a really dumb question, and I dont know if it relates to permisions, I'm sort of new to NT/2k, I installed diablo 2 as administrator, I have a regular user account setup for some other people using my comp, I made sure the user had full control over the diablo 2 folder, but when I login as that user the program says it can't read the cd properly, I can list the contents of the cd and execute files off it, but I can't get the game to play, any help? | |
|
| Hi Terje,
Thank you very much for explaining further. I hope I'm not bothering you too much. I really appreciate all your feedback.
I checked the help files but I can't really find anything that mentions this thing which I like to call an anomally.
I know its like I'm beating a dead horse to the ground or however that saying goes but I think it would be a good idea for MS to include some kind of popup message telling the user that is setting deny permissions on a folder where it really won't be denied, that it won't be denied because so and so.
I mean, why bother having so many selectable choices such as "This folder only", "allow... inheritable...", and deny "delete subfolders and files" special permissions when it's really not going to do that.
quote:
The delete subfolders and files special permission is different from other permissions in that you give it to one object, but it has consequences for another. You can turn on or off the permission, but unlike inheritance you can not override the effect on the child in the child itself. Neither can you disable its effect on the child as you can disable inheritance.
this consequence only seems to run one level deep, am I correct?
bottom line Terje, is there ANY way to create a folder directly in C:\ (the root?) without changing the original permissions set by win2k when it was installed, without the ability for anyone to be able to delete it? I think that is basically what is driving me crazy, not being able to accomplish this.
Thank you and I hope this will be the end of my questioning on this subject. Once again I really appreciate your effort in helping me understand. | |
|
| Here I am again.
I tried something new.
I am not sure if you have Windows 2000 or not but look what happens when I do this.
I added a user (perhaps not necessary like you pointed out before) to the C:\ Security dialog and specifically denied both Delete special permissions in the advanced dialog.
Then created a folder and didn't touch permissions.
This did exactly what would be assumed on what you have been telling me so far. I couldn't delete the folder.
Good so far.
Next, since I didn't touch the default permissions on the new folder that I created, of course it was inheriting everything from C:\.
I deselected the inheritance checkbox and decided to select copy. Then I removed the particular user I had added to C:\ in the first step.
My assumption was that since Deny Delete was specifically set on the parent, C:\, and that making any changes to the folder itself would not change anything with respect to the delete special permissions, that, I would still be denied of deleting the folder. But once again, things seem to work differently!
I was able to delete the folder.
This is now acting the way I originally thought folder/file permissions work. When inheritance is turned off, and permissions set specifically to a folder only or files and folders, etc, then THAT is what I am setting permissions for, regardless of parent settings.
But to me this contradicts what you have been telling me.
Am I crazy?
I'm beginning to feel like it. | |
|
| Well I'm putting this issue to a rest now. I found this article that I think explains everything. I hope you might find it useful.
Its Q152763 on the MS knowledgebase. Something called FDC. I find it funny that it was made this way to maintain posix compliance.
Take care Terje and see ya around  | |
|
| Regarding your question, I found this on the microsoft win2k help ->
http://www.microsoft.com/windows200...fessional/help/
Here it states :
Groups or users granted Full Control for a folder can delete files and subfolders within that folder regardless of the permissions protecting the files and subfolders.
Because you created a folder in the root ie:
c:\test folder
I am assuming because the everyone group by default has FC of the root this enables them to delete folder under the root regardless of permissions set in those folders
??
just a thought
mark |
|
|
|
|