Ex: RE: SSPCPP-961

[Paul B. Henson]

> From: Rod Widdowson
> Sent: Wednesday, March 8, 2023 3:12 AM
> 
> Sigh.  One would have thought that a CreateDirectory operation would only
> apply to created directories.

Yep. After reviewing the wiki and the commits associated with the change, I had a whole response already written to the person who asked me about it saying it should not impact an existing installation, only a fresh one.  Then I decided to do some testing this to make sure, and was surprised to see it mucked around with them on a patch install as well.

> way of doing the right thing, just a series of slightly less wrong ones.

Ooooh, that sounds like a great slogan for Microsoft products - "Why waste time doing the right thing when you can so quickly accomplish so many slightly wrong things?" ;).

>  But TBH the whole area of ACLS, and SACLS and DACLS and
> ownership gets very complicated very quickly.

I managed a ZFS fileserver once which was accessible both via unix using NFSv4 and Windows via CIFS, and shared the same underlying ACL permissions with both. It was amazing how horribly screwed up the ACLs became when someone tried to change them via Windows. A simple change to an ACL with only a few allow entries suddenly became a dozen twisted nested allow and deny entries with the permission sets split across them 8-/.

> Anyway, and subject to the project team's agreement,  I think this might be
> fixable if you want to pop in a JIRA case.

SSPCPP-970, thanks.

> Meantime I will point you to the WEBSERVER_USER property.

I did see that and told the person I was talking to to be sure and use it if their IIS service account wasn't a member of the Users group.

> In theory at least (see the comment above) we do not own that directory.

I agree, and would not expect you to change permissions at that level in case other stuff was installed underneath it. It just seemed like the same vulnerability would apply so the additional complication of the initial fix might not be worth the potential headache if you could still do it just at a different level.

> Also in general top level folders are already under a restricted ACL (again in theory).

Under Windows 10 all authorized users can modify stuff at the root and inherit modify on any new directories created there. It might be different under Windows server?

> You have to stop any process which has executables open in that tree
> (mostly shibd_default).

I went back and tested again, and I was actually able to directly rename the shibd binary even while the service was running, but not the opt directory.

Dunno. Windows. It's a vulnerability treadmill no matter what you do.

Thanks for the response...