Files configuration endpoint

[jimmyca15]

File Configuration Endpoint

The IIS Administration API has many places that require access to the file system. A few examples include creating web sites, setting the directory for log files, and the file system API. The configuration for all this file access resides in the application's appsettings.json file. Historically users needed to edit this file by hand to open up new parts of the file system to the API. Now users that have access to the system access policy can use this endpoint to add new file system locations.

Who Has Access

This endpoint is locked down by the system access policy in the appsettings.json file security section.
By default only the installing user will have access. To grant access to additional users they will need to granted access to the system access policy which is the highest privilege of the IIS Administration API and allows users to take advantage of the fact that the service runs as the System account.

Example Improved Scenario

Creating a site in C:\sites

Before

• Install IIS Administration API
• Take ownership of appsettings.json
• Grant modification privilege to current user for appsettings.json
• Edit appsetings.json files section by hand and add the C:\sites location
• Restart Service
• Create website in C:\sites via IIS Administration API

After

• Install IIS Administration API
  Note: Installing user is automatically added to the system access policy of the API so they have access to this new file settings endpoint
• Use the file configuration endpoint to add the c:\sites directory to the allowed locations
• Create website in C:\sites via IIS Administration API

Endpoint

/api/files/settings

  "skip_resolving_symbolic_links": "false",
  "locations": [
    {
      "alias": "inetpub",
      "path": "%systemdrive%\\inetpub",
      "claims": [
        "read",
        "write"
      ]
    }
  ]

Supported Operations

• Get
  • Lists all locations and their allowed access (claims)
• Patch
  • The list of file system locations can be updated.
    *All desired locations must be sent in the body of the request.
  • Failure to list a location in the update will result in the configuration for the location being removed.

[jimmyca15]

@drago-draganov suggested that it would be better if this was exposed as

/api/files/locations and each location was its own resource that could be deleted, patched and created individually.