| Date: | July 26, 2007 / year-entry #273 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070726-00/?p=25833 |
| Comments: | 9 |
| Summary: | When you call up the file security dialog, you'll see options like "Full Control" and "Read and Execute". That's really nice as friendly names go, but when you're digging into the security descriptor, you may need to know what those permissions really map to when it comes down to bits. First, the summary attributes: Friendly... |
When you call up the file security dialog, you'll see options like "Full Control" and "Read and Execute". That's really nice as friendly names go, but when you're digging into the security descriptor, you may need to know what those permissions really map to when it comes down to bits. First, the summary attributes:
If you go to the Advanced view, then you get much more precise control:
(In the Advanced view, you control inheritance from the "Apply to" drop-down combo box.) Note that the "Delete Subfolders and Files" and "Delete" attributes together determine whether you can delete a file or subdirectory: You can delete an item either if you have [Update 2pm: INHERIT_ONLY_ACE should be OBJECT_INHERIT_ACE.] |
Comments (9)
Comments are closed. |
Brilliant! I was actually looking for exactly this information a while back and ended up giving up and just cobbling together something that covered the simple cases. Thanks Raymond.
This will prove very useful to me as well. Thank you, Mr. Chen.
JamesNT
The WinXP "Help and Support Center" has a topic on Permissions that has links with similar descriptions (but still not nearly as detailed as what Raymond provided here) of the meanings of the terms used in the security dialog for all types of objects, including:
– file & folders (what Raymond described above)
– Shares
– Registry keys
– Services
– Printers
– Term Serv connections
– Group policy objects
– WMI objects
Even though the descriptions in WinXP help don’t go to the level of detail saying which Win32 identifiers map to the permissions in the UI, they do get detailed enough that you can usually figure out the mappings.
%windir%temp already works like this. It gives create file rights to BUILTINUsers and full control to creator/owner.
Although it’s probably not shell related, I’d be more interested to know how GENERIC_READ and GENERIC_WRITE permissions map to ACLs. From what little research I’ve done, it appears that various subsystems (object manager, file system, etc) have tables that map the GENERIC_XXX to specific permissions, but I haven’t been able to find all the mappings.
I believe this "owner can delete" concept doesn’t entierly apply. If a user creates a subdirectory and denies permission to the directory, the owner can’t delete the directory and the files beneath it. Is there any workaround for this?
Say if I want to implement a directory where any user can create/delete files but I have full access to the files/folders underneath. Assuming I don’t have admin rights..
*Thanks* a lot Raymond!
With that info, I managed, at last, to do what I always wanted: create a common temp directory for all users! Previously, I relied on the fact that there was always a program with a open temp file to deny me the temp directory deletion (I have a script to delete its content that does a "rd /s")
Now I truly don’t have the right to delete it.
For anybody who’s interested, and for my future use I’m sure, here is the purpose and how to do it:
Purpose:
Having a common ‘temp’ directory that anybody can write to and in which one can only read/modify/delete his/her files.
I set it up so that administrator is also impacted, so you will have to have another special account+ACL if you want to easily clean it.
In my example, the temp directory in question will be C:temp
How to do it:
– On the parent of the ‘temp’ directory (C:), remove the "Delete subfolders & file" permission from the users you want this method to apply. In my case, since "Users" only have Read/Execute permission on C:, this means that I only remove this permissions from the Administrators group(*).
– Still on the parent (C:), add a new ACL for "CREATOR" that will apply only to contained files and subfolders. For this ACL, only set the "Delete" permission.
– Create the temp directory.
– Remove the ACL inheritance
– Make effective the following permissions:
– Admin group/This folder only: full control minus delete and delete children
– Users group/This folder only: read/execute plus file and folders creation
– CREATOR/This folder and everything inside: full control
I hope I didn’t forget anything. Anybody, please feel free to correct me if this method is wrong in any way and thanks again Raymond!
(*) I had previously removed my administrator login name from the list on C: since its right do not, in my opinion, need to be explicitely specified as they are not different from those of the group Administrators… I thought it was a duplicate entry.
"Say if I want to implement a directory where any user can create/delete files but I have full access to the files/folders underneath. Assuming I don’t have admin rights.."
If you don’t grant the WRITE_DAC permission on child objects that should do it, shouldn’t it? Since they won’t be able to alter the permission, you’ll always have access.
Alternatively you could give the account that needs to delete them the Take Ownership permission, though that’s a little heavy handed.
Well, mine doesn’t work like this. I don’t remember messing with its permissions but maybe I did. Mine is setup so that Users have Read/Execution access to c:windowstemp. So they cannot create files in it but they can read Admin’s temp files! Looking at how stupid that situation is, I clearly must have done something wrong in the past…
If I look at one of my newer PC, the situation is different, much closer to what I wanted, except that while Users can create files and have directory traversal permission, they can’t list its files, which disables my "rd /s" temp cleaning solution. The other problem is that Admins can read & delete Users’ files, but I can understand that my personal preference is not the default :)