次の方法で共有

WebDAV, Source, and Read Permissions on IIS

  • [アーティクル]

Question:

Hello:

With the new WebDAV upgrade in IIS 7.0, there is a permission named "Source". How is the "Source" permission different from "Read" please?

What if "Source" is enabled but "Read" is not??

Answer:

Source and Read permissions control different behaviors.

Read permission controls whether the IIS Static File Handler allows the requested resource to be retrieved (i.e. read) as the response. This action is subject to all behaviors of the IIS Static File Handler, including the MIME Type check.

Source permission, when WebDAV functionality is present (i.e. installed/enabled), controls what happens when the request has the Translate: header. The logic looks like:

 If Translate:f AND "Source" is enabled Then
    // Handle with Static File Handler
Else
    // Continue processing normally
End If

Thus, the interesting combination for "Source" happens when:

  1. Execute Permissions is either "Scripts" (or "Scripts and Executables") AND
  2. The requested resource extension has an applicable Application Mapping (or is a DLL/EXE) AND
  3. Request has Translate:f header
  4. "Source" Permission is enabled (along with Read Permission)

In this special combination, the "un-translated" resource (i.e. the script source or DLL/EXE executable binary) gets served as the response by the IIS Static File Handler, INSTEAD of the usual execution of the script or binary to generate the response. This mechanism is how a WebDAV client (via Translate:f) as well as WebDAV server (via Source Permission) cooperatively implement WebDAV behavior. Both client and server have to implement their part in order for WebDAV to work.

Note that this allows WedDAV clients to retrieve of raw source code of an ASPX file even though the virtual directory has Script Execute Permissions and a .aspx Application Mapping, while a normal HTTP client will see response generated by running the ASPX file.

As for what happens when Source is enabled without Read - that is actually an incomplete question.

  • If Translate:f is present on the request, then a 403.2 is returned because the Static File Handler requires the Read permission and a MIME Type to be able to serve the response 
  • If Translate:f is NOT present on the request, "Source" has no meaning and the request processes normally, as follows...
    • If the resource is handled by the Static File Handler, then a 403.2 is returned because of the missing Read Permission.
    • If the resource is handled by an Application Mapping or DLL/EXE, then it depends on the Execute Permission.
      • If it is None, then it is 403.1 for Application Mapping and 403.2 for DLL/EXE because of the missing Read Permission
      • If it is Scripts, then Application Mapping executes and 403.2 for DLL/EXE because of the missing Read Permission
      • If it is Scripts and Executables, then both Application Mapping and DLL/EXE executes

Note that when I mention Application Mapping and DLL/EXE from an IIS6 perspective, it just maps into handlers on IIS7. The logic remains the same. To the astute reader - yes, you can play around with the ordering of handlers and modules on IIS7 to generate any set of behaviors, including the one mentioned above. And yes, I consider all such permutation of behaviors valid because that is the power of a completely extensible platform. You are empowered to shoot anything else, including yourself, in the head.

//David

Comments