Windows 7: icacls deny delete also denies read?
First my overall goal. The program I am writing creates data files (XMLs) that need to be viewable by all the users and another program reads the data in. However, I need to ensure that my program is the only one that writes to the files and that users cannot delete the files (on accident). I realize that there are ways around the permissions but making it difficult or purposeful to edit or delete the files is enough. I think permissions is the way to go so I am working with icacls, and struggling. The documentation and web searches I find don't seem to really answer how to do what I want, or how to "debug" the privileges. So my first approach was to have the program run as a different user and have the program deny rights to all the other users. It is doable, but somewhat a pain to query all the users but one and then loop through them to deny access. Second approach. Deny the "Users" group using Icacls. So the program creates the file and then denys the "users" group access. Then if it needs to make an edit it just grants "users" full access, edits the file, and then denys access again. This appraoch seems hookie, but should work. So my problem\question: If I use " icacls "C:\file.xml" /deny Users:(D) " I can no longer delete the file. Success, however I can also no longer open it to read in IE, notepad, or my program. If I call " icacls "C:\file.xml" /grant Users:R " nothing changes I still can't open it. But if I right click on the file and go to security>>advanced >> change permissions and then edit the deny and add allow "read data" I can open the file just fine. So any ideas why deny:(D) seems to also be denying all reading? Am I just looking at this all wrong and is there a better way? I haven't even started down the deny write aspect either. Thanks
February 3rd, 2012 3:43pm

Have you looked at the other permissions you can give through icalcs? icacls file /grant Administrator:(D,WDAC) - Will grant the user Administrator Delete and Write DAC permissions to file perm is a permission mask and can be specified in one of two forms: a sequence of simple rights: F - full access M - modify access RX - read and execute access R - read-only access W - write-only access a comma-separated list in parentheses of specific rights: D - delete RC - read control WDAC - write DAC WO - write owner S - synchronize AS - access system security MA - maximum allowed GR - generic read GW - generic write GE - generic execute GA - generic all RD - read data/list directory WD - write data/add file AD - append data/add subdirectory REA - read extended attributes WEA - write extended attributes X - execute/traverse DC - delete child RA - read attributes WA - write attributes So I think the command you want to do would be.... icacls "C:\file.xml" /deny Users:(D,WA) icacls "C:\file.xml" /grant Users:(R,RC,RD,RA) I'm not sure you need all the different read ones(play around with it i guess)...Basically you use the paranthesis for the specific rights in the second section up there. info is here http://support.microsoft.com/kb/919240
Free Windows Admin Tool Kit Click here and download it now
February 8th, 2012 11:20am

Hi EvanC11, Finally I found a method may achieve what you want: 1 icacls c:\file.xml /deny users:D 2 cacls c:\file.xml /E /G users:R Note: icacls and cacls are different command. Hope that helps. Regards, Leo Huang Leo Huang TechNet Community Support
February 8th, 2012 8:32pm

You should not use the access rights M,RX,W, GW,GR, GX,GA and D on a file or directory because icacls does not set the permission correctly when used for a DENY ACE. If you save the access permission to a file you'll see a difference between the Text/GUI display (security dialog) and this output: icacls file /save output.txt D:AI(D;;0x110000;;;<A Sid>) The access right 0x110000 is #define DELETE (0x00010000L) #define SYNCHRONIZE (0x00100000L) You can see that not only DELETE access is denied but also SYNCHRONIZE. This access right is necessary for the function WaitForSingleObject (see MSDN) and this is the reason why you can't access such a file anymore although you have READ and even WRITE permission. (I guess even system internal functions need this right because I could not open a file with CreateFile even without setting the SYNCHRONIZE bit in DesiredAccess parameter.) To remedy that you can use the other access rights or in case of DELETE you have to use your own DACL string and load it using "/restore" : Tip: save a template first and remove the digit 1 at position 6 (from the end) like: D:AI(D;;0x010000;;;<A Sid>)
Free Windows Admin Tool Kit Click here and download it now
March 21st, 2012 7:14am

You should not use the access rights M,RX,W, GW,GR, GX,GA and D on a file or directory because icacls does not set the permission correctly when used for a DENY ACE. If you save the access permission to a file you'll see a difference between the Text/GUI display (security dialog) and this output: icacls file /save output.txt D:AI(D;;0x110000;;;<A Sid>) The access right 0x110000 is #define DELETE (0x00010000L) #define SYNCHRONIZE (0x00100000L) You can see that not only DELETE access is denied but also SYNCHRONIZE. This access right is necessary for the function WaitForSingleObject (see MSDN) and this is the reason why you can't access such a file anymore although you have READ and even WRITE permission. (I guess even system internal functions need this right because I could not open a file with CreateFile even without setting the SYNCHRONIZE bit in DesiredAccess parameter.) To remedy that you can use the other access rights or in case of DELETE you have to use your own DACL string and load it using "/restore" : Tip: save a template first and remove the digit 1 at position 6 (from the end) like: D:AI(D;;0x010000;;;<A Sid>) I have a similar problem as OP. Can you please help? Here is my post - http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/51c631d1-b8bf-44b7-8ee7-8451303a87e9 Sorry, it is not my intention to hijack this post but no one seems to respond and it is kind of a pressing problem to me
May 24th, 2012 1:23pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics