IIS log folder permissions not being inherited

Question

We have a Log folder set up on our web server, with permissions set for a specific AD group to be able to read it (developers who need to see error reporting, but who do not have administrator permissions to the box).

This works fine for logs that already exist, but whenever IIS creates a new sub folder (with the name pattern "W3SVCx"), the permissions from the parent folder do not inherit down. Instead, these folders are visible only to administrators.

How can we get IIS to write these logs with the correct inherited permissions, without giving administrator access to users who should not have it?

Solution 1

IIS creates the W3SVCx folders after the first request to a newly created site, it also sets the NTFS permissions on it regardless of the permissions of the parent folder and its inheritence settings. The permissions it sets are:

NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)

I don't know of any way to tell IIS not to do this. You need to remember that after you set up a new site, hit it once and then set the permissions on the log folder.

If you set up many sites, use a script instead. I use PowerShell:

New-WebSite -Name "peter.superuser.com" -port 80 -id 106 -PhysicalPath "C:\inetpub\peter.superuser.com" -HostHeader peter.superuser.com
(New-Object System.Net.WebClient).DownloadString("http://peter.superuser.com")
start-sleep -seconds 1
& icacls.exe "C:\inetpub\logs\LogFiles\W3SVC106" /Q /grant "BUILTIN\Users:`(OI`)`(CI`)`(RX`)"

I first create the site, then hit the home page, wait a second and then set the permissions on the log folder.

If you don't know the Id of the site in advanced, use

$newId = (get-childitem IIS:\Sites | where{$_.Name -eq "peter.superuser.com"}).Id
& icacls.exe "C:\inetpub\logs\LogFiles\W3SVC$newId" /Q /grant "BUILTIN\Users:`(OI`)`(CI`)`(RX`)"

to get the Id after you created the site.

To use this you need to enable scripting for IIS, depending on your OS.

Solution 2

I use the following workaround on any new IIS 7/8 installation:

1. Set desired permissions on folder C:\inetpub\logs\LogFiles

2. Modify existing log folders to inherit permissions

   icacls C:\inetpub\logs\LogFiles\W3SVC* /inheritance:e
   

3. Pre-populate the first 99 log folders W3SVC1...W3SVC99 so that they inherit permissions before IIS even tries to create one of them. IIS does not modify permissions when a log folder already exists.

   REM cmd style
   for /l %%G in (1,1,99) do md C:\inetpub\logs\LogFiles\W3SVC%%G
   
   # PowerShell style
   1..3 | % { md C:\inetpub\logs\LogFiles\W3SVC$_ }   
   

It's not pretty, but it gets the job done.

Comments

[sthames42]

I answered a related question that may provide some more insight into IIS logging directory permissions. See my answer here: stackoverflow.com/a/68687101/2245849.

[Sean Worle]

The main problem is that this is not entirely correct - IIS creates these folders after the site is created, and also periodically from then on as they get full. On our servers, it creates a new folder roughly once per day, so that each folder contains the day's logs. Are you saying the only way to handle this would be to have a scheduled job run to change permissions every day?

[Peter Hahndorf]

@Sean - What version of IIS are you using. At least on 8, the folder is not created when you create a site but after the first hit on the site. The permissions on that folder are then not changed anymore. There is only one folder per site. By default a new file is created every day. How can folders get full? You can change the 'Log File Rollover' from 'Schedule' to 'Max file size'. I have not done that but I doubt it will change the general behavior of the logging.

[Sean Worle]

We are using IIS 7.5. It looks like I may have been mistaken - you are saying that the folders are only created the first time the site is hit. That could be the source of the misapprehension that these folders were being created continually. It's a little extra work to do when we create a site, but as long as they are not continually being created, that may be ok. Thanks.