How to use icacls.exe to fully enable users to subfolders/files

[Tom]

In an installer, I'm trying to use icalcs.exe on Vista to fully enable all
user access to the folder C:\ProgramData\MyApp and all subfolders & files.

Can someone help me out with the perms arguement? Specifically, I can't
figure out how to get inheritance to work so that new files and folders
inherit the full rights.

I thought the command below would work, but it won't even run:

C:\Windows\System32\icacls "C:\ProgramData\MyApp\*.*" /T /C /Grant
UsersOI,CI,MA)

 

[Tom]

So, now I've got the syntax right so the command at least runs:

C:\Windows\System32\icacls "C:\Junk*.*" /T /C /Grant UsersOI)(CI)(MA)

But it still doesn't seem to be working properly.

I need to set the ACL so that even if someone with admin rights creates a
file or folder in or under MyApp, users have full rights over it.

 

[Tom]

Sorry to be clutter this thread. I've been working on this for quite some
time, and carefully reading anything I can find on the web on icacls, so
it's not that I haven't at least tried to do my homework.

Below is a command that I *think* should do what I want. I'm having trouble
with the OI and CI parameter syntax.

Any help?

iacls "C:\ProgramData\MyApp*.*" /T /C (OI) (CI) /Grant Users:F

 

[Jesper]

First, what you are trying to do is probably a bad idea. You should not let
low-privileged users write data that is consumed by high-privileged users.

Second, MA stands for Maximum Allowed. It is not a flag you can use when
specifying permissions. It is a flag you use when to try to open an object
and you do not care what permissions you get to the object, nor about
security. In that case, as long as you have any permissions at all you get a
valid handle back with whatever permissions you have. It is virtually always
a bad idea to use MA in an any call.

Now, the syntax you want is this:
icacls object /grant userflags)(perms)

/t traverses the directory. I presume you have a brand new directory or that
you at least created everything so it inherits permissions from parents? In
that case /t is unnecessary. /c indicates that the command should continue on
file error, such as that the file is locked. More than likely you don't need
that flag either.

The folder specification you state is invalid. C:\ProgramData\MyApp*.* will
set permissions on all objects in C:\ProgramData called MyApp*.*, such as
MyAppFoo.Bar. It will not work if you have a folder called
C:\ProgramData\MyApp.

Assuming that folder was just created and all you want to do is add a
permission to it, this command would suffice:

icacls c:\programdata\myapp /grant UsersOI)(CI)M

There is lots more on icacls in the book referenced below.

 

[Tom]

Thanks, Jesper!

I think I'm close to having what I need! The problem I'm trying to solve is
that I have legacy app that uses an older installer (Wise32) which I'm stuck
with for the time being. It must run, like any installer, with admin rights.

But, it doesn't know anything about the ACL. It creates a series of folders
as admin.

I want to change the entire folder tree so that all users have "Full
Control" security property set, which I believe will let them do anything
with the files/folders that they want. So, I'm not trying to let
low-privileded users write data that is consumed by high-privileged users
(although I appreciate your cautioning me against that). I just want all
users to be able to access files & folders created by an older installer.

And, I want the users group "Full Control" security setting to be inherited
by any new files or folders created in the folder tree.

From my experimentation with the syntax you gave me, I don't think it does
quite that.

Would you be so kind as to suggest syntax that would set the users group so
it has "Full Control" of all files in a tree, and this is inherited by new
files?

Thanks so much!!!

PS That's for the book reference. I've already ordered it from Amazon!

 

[Jesper]

Yes, the syntax I gave you gives users modify permissions, not full control.
They can't change the permissions that way, but they can read, write, create
and delete. I set the OI (Object Inherit) and CI (Container Inherit) flags
too. That way any object or container that anyone creates gets these
permissions too.

The only thing I did not do is traverse it down the folder hierarchy in case
other containers and objects underneath myapp did not inherit their
permissions from the parent. There is no really easy way to do that, but you
can handle it by running this command first, before the one I gave you
earlier:
icacls c:\ProgramData\MyApp /reset /t

That will reset the permissions to the default and set the inheritance bit.
When you then run the command I gave you it should set the right permissions
on the whole hierarchy.

Hopefully this will get you there. I still think you should question why you
want users to write data to ProgramData instead of their own personal AppData
folder, but there may be a good reason there.

Oh, and let me know what you think of the book. You can reach me at
http://msinfluentials.com/blogs/jesper.