Improved Permissions

From Davical
Jump to: navigation, search

At 0.6.0 the permissions in RSCDS were limited to "All", "Write", "Read" and "Freebusy", which should be sufficient for the functionality available at present, but may need to be extended further in future.

One thing that is not covered well at the moment is:

  • See collections (but not their contents)

The DAV permissions are as follows:

  • read
  • write
  • write-properties
  • write-content
  • unlock
  • read-acl
  • read-current-user-privilege-set
  • write-acl
  • bind
  • unbind
  • all

Since none of those cover what might be desirable for Freebusy there is an additional one defined by CalDAV, which is:

  • CALDAV:read-free-busy

The 'bind' permission means 'can PUT a new event', the 'unbind' permission means 'can DELETE an existing event' - why do people have to invent new names for these sorts of things? I can't for the life of me see what would be wrong with 'create' and 'delete' permissions.

More recently, a design is taking shape for full implementation of the DAV permissions model. See Permissions Redesign for the details of work being attempted in the 0.9.x series.

Detailed Implementation State

I found this nice table in the DAV ACL specifications, so here is the full comprehensive state of RSCDS in terms of implementing this:

GET <D:read> Done
HEAD <D:read> Done
OPTIONS <D:read> Done
PUT (target exists) <D:write-content> on target resource Done (1)
PUT (no target exists) <D:bind> on parent collection of target Done
PROPPATCH <D:write-properties> Done (1)
PROPFIND <D:read> (plus <D:read-acl> and <D:read-current-user-privilege-set> as needed) Done (2)
DELETE <D:unbind> on parent collection Done
LOCK (target exists) <D:write-content> Done (1)
LOCK (no target exists) <D:bind> on parent collection Done (1)
MKCOL <D:bind> on parent collection Done
MKCALENDAR <D:bind> on parent collection Done
UNLOCK <D:unlock> Done (1)
REPORT <D:read> (on all referenced resources) Done
FREEBUSY <CALDAV:read-free-busy> on parent collection Done
COPY (target exists) <D:read>, <D:write-content> and <D:write-properties> on target resource HttpMethodNotSupported
COPY (no target exists) <D:read>, <D:bind> on target collection HttpMethodNotSupported
MOVE (no target exists) <D:unbind> on source collection and <D:bind> on target collection HttpMethodNotSupported
MOVE (target exists) As above, plus <D:unbind> on the target collection HttpMethodNotSupported
ACL <D:write-acl> HttpMethodNotSupported
CHECKOUT <D:write-properties> HttpMethodNotSupported
CHECKIN <D:write-properties> HttpMethodNotSupported
VERSION-CONTROL <D:write-properties> HttpMethodNotSupported
MERGE <D:write-content> HttpMethodNotSupported
MKWORKSPACE <D:write-content> on parent collection HttpMethodNotSupported
BASELINE-CONTROL <D:write-properties> and <D:write-content> HttpMethodNotSupported
MKACTIVITY <D:write-content> on parent collection HttpMethodNotSupported

Although this looks a bit daunting it's not too bad, since clients should issue an OPTIONS request to discover the supported methods, and looked at that way only PROPFIND is presently incomplete. It would be nice to get a few more of these HTTP methods supported though!


1. This requires "write" privilege which is not presently subdividable into "write-properties", "write-content" and so on.

2. This requires "read" privilege which is not presently subdividable into "read-acl", "read-current-user-privilege-set" and so on.