Write and Execute Permissions on the same folders?!

May 30, 2008 at 11:35 AM
I assigned write permissions to the 3 folders as advised in the documentation. (NB: This should be updated to also say delete permissions are needed as the application crashed when trying to delete a file in the log directory).

As a matter of course I always remove execute permissions on folders where the IIS Identity has write permissions. However doing this seems to prevent it from loading any templates and all the pages come back unstyled.

I haven't looked at the code yet can anyone set my mind at rest that leaving both permissions is totally secure and that there's no way any malicious user can upload an aspx page to, say, the content directory then execute it by requesting the URL?
May 31, 2008 at 4:28 PM
#1 The system is basically secure. See this for more on that: http://dasblog.info/HowToSecureYourDasBlogInstallation.aspx
#2 The security settings on the three primary write directories has nothing to do with your loading templates or styles, that must be just a coincidence in this case. (Most probably a configuration problem of some type)
#3 The write access for these directories is not NTFS write access directly but IIS write access which does not give the IUSR account write access, but system application write access.
#4 The only NTFS security settings for write and other control should be limited to "Network Service", it is safe to give the Network Service full control, but full is not required.
In fact when I view my sites with the NTFS security snap-in the IUSR account does not appear to have any security rights for the entire site; while IIS is giving anonymous read rights to IUSER the NTFS security does not see that account at all for any directories.

Cheers Tom

Jun 1, 2008 at 12:38 PM
Thanks Tom for your detailed response.

I have set Execute permissions to none for all three folders and all the pages appear correctly now. Bit strange as I haven't made any config changes in the meantime so I'm not sure why I was getting the issue previously.