How do you set multiple acls on the same directory?

[slang]

I'm trying to specify access control for a directory for IUSR_MACHINE and IWAM_MACHINE.

The Set Access Control command, however, only allows for one named User Account. I tried issuing multiple Set Access Control commands but the resultant acls are not combined.

How do I specify acls for multiple named User Accounts?

[MichaelNesmith]

If you call multiple ACL commands, that should really do it. Notice how when you specify an ACL, existing ACLs are not lost. So specifying multiple ACLs should do it.

Explorer's ACL viewer may not immediately refresh the information. This has been observed by InstallAware and our customers. So be on guard for that.

[slang]

Thanks Mike for the reply but after working this problem for the better part of 6 hours, I really think there is a bug in IA.

I appreciate your comment "Explorer's ACL viewer may not immediately refresh the information". Indeed, a Google search reveals others experiencing this phenomenon.

To verify that the problem is not simply latent Explorer ACL viewing, I did the following:

- In a dos window, I displayed the ACL's using the CACLS command. Most, but not all, the new ACL's showed up.
- I rebooted. Again, not all of the new ACL's showed up. It's hard for me to imagine that the missing ACL is somehow going to appear when it doesn't show up after a reboot.

Sequencing the Set Access Control commands as follows:

Set Read Write Permissions on File System Object "$TARGETDIR$" for LUKE\\IWAM_LUKE
Set Read Write Permissions on File System Object "$TARGETDIR$" for LUKE\\IUSR_LUKE
Set Read Write Permissions on File System Object "$TARGETDIR$" for LUKE\\ASPNET

results in an ACL for LUKE\\IWAM_LUKE and LUKE\\ASPNET; LUKE\\IUSR_LUKE is missing.

Changing the above Set Access Control commands so that IUSR_LUKE comes first and IWAM_LUKE comes second results in an ACL for LUKE\\IUSR_LUKE and LUKE\\ASPNET; LUKE\\IWAM_LUKE is missing.

It is interesting that in both cases LUKE\\ASPNET is represented by an ACL but for some reason I can't get all three - EVEN AFTER REBOOTING. Thinking that this might somehow be an XP bug, I ran the install on a win 2k machine and experienced the same problem.

I have experimented with this as much as I can. I would be most appreciative if you could look into this further, perhaps run a similar Set Access Control command sequence on your test machine.

Thanks

[MichaelNesmith]

I tried what you said on my temp folder. Before the process, there were only a couple users with permissions. After the process, there were 4 new users (I tested with 4). However only two were the users I had named. The others were not - in my case, ASPNET and IIS_WPG did not show up, and IUSR_ and IWAM_ did show up. However, there were 4 new users total!

So I noticed Explorer is displaying, for example, the Users group as having permission to the folder, and ASPNET is a member of Users. I can only guess why this is so - but the net result is that, despite the confusing appearances, the indicated users are indeed being given access.

[slang]

Thanks Mike for your quick response but it does not appear to exactly relate to my problem.

My issue is NOT whether or not the ACLs show up right away in Explorer but rather that they are not all being created, as revealed after a reboot. I don't care whether they show up right away in Explorer as long as they get created.

Since you mention IIS_WPG, I presume that you are testing with IIS6. Is it possible to run a test with IIS5 to replicate my problem? I don't think I'm unique in wanting to specify ACLs for IUSR_machinename, IWAM_machinename, and ASPNET for IIS 5 or IIS 5.1. I would think this a rather common requirement. I'd like to automate it in the install and not have to make it a customer manual effort.

Thanks again. IA rocks!!!

[MichaelNesmith]

Like I was saying...the ACL did get created. But it was shown by a different name. This might simply be part of Windows's ACL internals. But the new ACL was there and it gave the group that the user is a member of, and hence that user by virtue of inclusion in that group, access.

[slang]

Michael:

Because you don't experience the problem in II6 does not constitute proof that the problem doesn't exist with IIS5.

You're not addressing my issue. Is there a way I can escalate this problem?

[MichaelNesmith]

An ACL has nothing to do with the version of IIS. Please read my message carefully and you will understand what I am saying. If you don't believe I have been able to help you please email support at installaware dot com.

[slang]

I would agree with you that ACL's should not have anything to do with the version of IIS but there is clearly something different between your test environment and mine. Perhaps the distinction is not IIS5 vs II6 but rather win2k/xp vs win3k.

In any event, I'm not fabricating the problem. The difficulty I'm experiencing will not go away simply because you don't think it exists.

[CandiceJones]

Oh - I apologize we led you to think that we are denying your report. This is absolutely not the case. You may have found a bug, something we cannot reproduce here. Or, as I suspect, the problem might be something simpler. Either way, we need your help in finding out!

Could you create an empty folder, and then remove ALL access permissions from it, in Explorer.

Don't use InstallAware for this. Use Explorer.

Then, in InstallAware, create an empty script with just one line - a Set Access Control command, which grants a READ privilidge to a single, named user to this folder, all hard-coded.

Run it. See if it works.

Then, change the command, to hard code another user name. Run it. See if it works.

Try out all three of your user names in this way...

...and in the process, keep an exact track of what appears in Explorer - which users have gained permission, which have not, and so on; after each step.

Hopefully, we will know more after this troubleshooting!

[MichaelNesmith]

Thanks Candice!

[slang]

Thanks Candice for responding to my issue.

I ran a series of tests as you requested.

Here is what I did:

1) Created an empty folder. I tried to remove ALL access permissions (disinheriting parent folder) as you asked but neither the installer nor myself could access it. So, I assigned access rights to just the Adminstrators group. If this is not correct, then I need to know how to get around access denied when running the installer.

2) I created an empty IA script and issued Set Access Control for the following test cases:
Test 1 - Applying permissions for domain\\IUSR_machinename
Test 2 - Applying permissions for domain\\IWAM_machinename
Test 3 - Applying permissions for domain\\ASPNAME
Test 4 - Applying permissions for domain\\IUSR_machinename and domain\\IWAM_machinename
Test 5 - Applying permissions for domain\\IWAM_machinename and domain\\IUSR_machinename
Test 6 - Applying permissions for domain\\IUSR_machinename, domain\\IWAM_machinename, and domain\\ASPNET

Attached is a word doc showing a windows explorer security viewer print screen for each of the above test cases. I assigned read and write permissions in each of the above test cases. After re-reading your posting, I realized that you only asked for read permission. So I re-ran the above tests and got the same results.

3) I manually assigned permissions to domain\\IUSR_machinename, domain\\IWAM_machinename, and domain\\ASPNET to demonstrate that windows does not prevent one from doing so. There is a print screen of this as well in the attached document.

4) Wrote another IA script that invoked cacls.exe instead of Set Access Control. Using cacls, all of the test cases produces the desired result. i.e., I was able to get all three security contexts assigned.


Since cacls works and Set Access Control doesn't, is it possible that Set Access Control is blocking what it believes is an invalid combination of security contexts? IWAM_machinename is used for out-of-process applications and IUSR_machinename is used for in-process applications. Since an application can't simultaneously be in-process and out-of-process, perhaps Set Access Control is not allowing both security contexts to be applied? From an installation viewpoint, one has no way of knowing how the customer intends to run his application, so I have to assign both security contexts in order to be failsafe. Windows allows both to be assigned, so I would hope that IA would as well.

Candice, I really appreciate the effort that you are making to address this issue. I've found a work-around (cacls) but I would really like to use built-in IA functionality in order to make my installer as reliable as possible.

InstallAware is a terrific product and your attention to this issue demonstrates that IA support is of the same caliber.

Please let me know if there is anything else I can do to assist.

Steve Lang
JeVal Software Engineering

File Attached:

PrintScreen.doc

[CandiceJones]

Hi!

Very interesting report! Could you also show us screenshots of which user groups the users you are creating are members of?

[slang]

Boy that was a quick response!

Attached is a word doc with the screenshots you requested.

FYI: I did not make these user group assignments. This is how win xp pro installed them. And, of course, the customer's machine could have different user group assignments.

File Attached:

PrintScreen2.doc

[MichaelNesmith]

I emailed support on your behalf - they were able to reproduce the issue and resolve it. An update will be available in the Monday-Tuesday timeframe.