| If a user has permission to write the acl property on a resource, the client should be able to modify the ACL and govern how the resource may be accessed. Although there is a standard mechanism to change the ACL, there is no standard way to change the owner of a resource. The owner property is a protected property and must be changed through administrator software access to the repository, not through WebDAV. 13.3.1 Setting ACL PROPPATCH is not used to change or set the ACL for a resource, even though PROPFIND is used to retrieve it. A couple of issues led to this choice: The server may parse the ACL, reorder it, or otherwise change the value, based on what the client submits. In other words, even if the client's request to change the ACL succeeds, the value of the acl property may not be exactly what the client sent. This doesn't correspond to the general model for PROPPATCH. The PROPPATCH method is used to change all kinds of metadata, most of which is not nearly as sensitive as the ACL. By using a separate method to set the ACL, the design allows firewalls to easily block attempts from outside to change WebDAV access control information.
The ACL request is simple enough: It takes a body with the proposed value of the acl property. It should not use the Depth header; it is defined only for one resource (see Listing 13-5). Listing 13-5 ACL request to set access control for a resource. Request: ACL /hr/index.html HTTP/1.1 Host: www.example.com Content-Type: text/xml; charset="utf-8" Content-Length: xxxx Authorization: xxxx  <?xml version="1.0" encoding="utf-8" ?> <D:acl xmlns:D="DAV:"> <D:ace> <D:principal> <D:href>http://www.example.com/principals/groups/hr-group/ </D:href> </D:principal> <D:grant> <D:privilege> <D:read/> </D:privilege> <D:privilege> <D:write/> </D:privilege> </D:grant> </D:ace> <D:ace> <D:principal> <D:property> <D:owner/> </D:property> </D:principal> <D:grant> <D:privilege> <C:administer/> </D:privilege> </D:grant> </D:ace> <D:ace> <D:principal> <D:all/> </D:principal> <D:grant> <D:privilege> <D:read/> </D:privilege> </D:grant> </D:ace> </D:acl> Response: HTTP/1.1 200 OK Date: Mon, 27 May 2002 15:23:19 GMT This example shows the read and write privileges being granted to the group hr-group, the administer privilege granted to whoever the owner is, and the read privilege granted to all principals. Whatever the ACL was before this request, it is replaced with this after the request. 13.3.2 Semantic Complications  | The ACL supplied in Listing 13-5 is fairly easy to understand in isolation. However, the reality of granting permissions can be much more complicated. WebDAV servers may use inheritance, ACE ordering, or other optional advanced features that can subtly affect the permissions algorithms. To understand these advanced features, both client and server implementors need to read the WebDAV ACL specification carefully. A brief overview: |
Not all servers parse ACEs in the same order or apply the same precedence rules. The acl-semantics property gives the client a hint how the server will order and parse ACEs. Most of the time, simple ACLs such as the previous one will be handled the same way by every server implementation. The complications only matter when the ACEs may overlap; for example, privileges are granted and denied to both users and groups containing those users. These options may be restricted in the next version of the draft. Servers can protect some ACEs. The client cannot remove ACEs protected by the server. The client may not know which ACEs are protected until it attempts to remove one of them. Servers can allow privileges to be denied in addition to being granted. The server must declare this in the acl-semantics property. All clients must be able to handle denied privileges as well as granted privileges when displaying ACEs to users, because it makes a big difference to the user whether a privilege is denied, granted, or neither. A server may support dynamic ACL inheritance. If a resource inherits ACLs, it processes access control rules not just from its own ACL but also from other locations. Because this inheritance is dynamic, changes in ACLs at those other locations may affect operations immediately on the original resource. The specification defines a property on resources that can point to those sources, so they can be examined as well. However, a user may not have permission to see all the ACLs that would be required to figure out what is allowed and what isn't. This feature is underspecified because it doesn't allow the client to figure out exactly what permissions are inherited or how to make permissions inheritable.
|
