SSPCPP-961

[Paul B. Henson]

I was looking at the changes from the subject issue. I initially would've expected the ACL to only be set on a fresh install where the directories did not exist, but empirically I see that a patch install over an existing deployment appears to update the ACL as well?

Given that the previous instructions were basically "set the ACLs to what you need" changing them after that has been done seems undesirable. If someone needs ACLs that are different than can be achieved with the new installer, is the expectation that they will set them explicitly after every patch update?

Also, the ACLs are only set on C:\opt\shibboleth-sp, not C:\opt which appears to still maintain modify permissions for all authorized users? What would prevent such a user from simply renaming C:\opt to C:\opt2, creating a new C:\opt and sp install hierarchy, and still exploiting the issue?

Although when I tried to do so, I was unable to rename C:\opt, as it said "The action can't be completed because the folder or a file in it is open in another program". I'm not sure how in the problem report the reporter was able to rename the sbin64 directory, although I was testing under Windows 10 not Windows server which might behave differently, or a subdirectory with only an executable running from a service behaves differently than a directory hierarchy with regular files opened. I must confess not to be intimately aware of all of the vagarities of Windows internals.

Thanks...


--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768