If I create a file (TestFile.txt) as an non-admin user in a folder that user has full rights to, then deny all access to that file from the server as an admin, the user can no longer modify, copy, rename, etc, but for some reason is still allowed to delete the file....
Here's the output from the icacls command:
TestFile.txt STATE\CV0228U:(N)
STATE\CV0228U:(I)(M,WDAC,DC)
STATE\CV0228U:(I)(F)
NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
STATE\DOA MPERA Staff:(I)(S,RD,X,RA)
I thought 'Deny' took precedence over all other rights implicit or inherited? Thanks
-
Deny permissions don't always trump other permissions. My suggestion would be to look at the effective permissions on the file for that user.
http://technet.microsoft.com/en-us/library/cc736316(WS.10).aspx
: Effective permissions on the file by the non-admin user shows only 'Read permissions' and 'Change permissions'. Everything else is unchecked. What would trump an explicit Deny?From joeqwerty -
The reason for this is because of this line:
STATE\CV0228U:(I)(M,WDAC,DC)That's inherited from the parent directory, and "DC" says it grants the "Delete Child" right. This allows rights-holders to remove files and folders in that directory. The explicit deny on the file itself is trumped in this case by the parent permission.
In order to do what you seem to want to do, avoid assigning the "Delete Child" right to the directory, and instead just assign "Delete".
: OK, so un-checking 'Delete subfolders and files' (but leaving 'Delete' checked) at the directory level did resolve this...so not ALL inherited rights are trumped by explicit? Thanks for you help!sysadmin1138 : @dsbigsky There is a reason Microsoft recommends against using the Deny right. It's somewhat unpredictable. In this case the rights of the file itself were never enumerated since it was a Child of a parent object that had the Delete Child right granted to it. Confusing, I know.: Good to know...I'm just trying different scenarios to understand Windows file security better (coming from a Netware background) Thanks again for the help.: Update: As i thought about this some more, it dawned on me that since this was a file I was denying access to, not a folder, it didn't have the 'Delete subfolders and files' attribute to take away, therefore the inheritance DID apply and the user could subsequently delete the file. I did the same test with a folder and didn't have the problem since the deny DID take away its 'Delete subfolders and files' priviledge. Thanks again everyone who responded.Kara Marfia : "the rights of the file itself were never enumerated since it was a Child of a parent object that had the Delete Child right granted to it" - you make it sound so *simple* ;)sysadmin1138 : @kara Simple in that delightfully non-obvious way Microsoft has sometimes.From sysadmin1138
0 comments:
Post a Comment