Permissions

From Davical
Jump to: navigation, search
From release 0.9.8 a new permissions model has been implemented. Essentially the permissions are now divided into two parts, from a user perspective:
  • Groups - ways of grouping a set of users together.
  • Grants - ways of providing access to a user, or a group of users.

Hopefully this much simpler view is easier to use and understand. In addition, 0.9.8 adds a concept of default privileges, so that as well as granting specific privileges to a user or group, you may grant privileges to 'everyone'.

Overview

Grouping

A 'group' is in effect any user, although in a normal installation these will be users who are specially set up to mediate between an individual and a set of permissions. The group (or someone with administrative rights to the group) controls who is a member. Groups may also be members of other groups, although multiple levels of nesting can add significant overhead and it is recommended that you keep this shallow.

Granting

The permissions which can be granted are fine-grained and directly map to the DAV privileges defined in RFC3744, and to the other privileges from CalDAV and so forth. All permissions are stored as a bitmap, so permission operations & tests are much simpler logical AND or OR operations.

Collection-level Privileges

While grants can still be applied between users, as with relationships in older DAViCal versions, then can now also be applied to collections, so a user might grant more public rights to one [calendar] collection, while restricting access to another.

Questions

How do I make new users members of a default group on creation

Prior to 0.9.8 it was possible to make new users automatically be set up with some default relationships. How do I do this now?

  • From 0.9.8 you should configure the targets of any default access to grant privileges by default. This is much more flexible, and means that an individual user might configure an individual calendar to have global access.
  • You can also configure the set of default privileges which are granted by new users (to everyone) by setting the $c->default_privileges value in your configuration file with something like:
$c->default_privileges = array('read-free-busy', 'schedule-deliver');

(i.e. to allow free-busy access from anyone, which is the default). The names of all of the privileges which can be used in the array are listed below.

Note that these default privileges are only what is assigned when a new principal (i.e. a user, group or resource) is created. If you change this default it won't apply to any previously created principals.

How can I translate my LDAP Groups into DAViCal groups

  • At present you cannot do this, but patches will be reviewed promptly!
  • This feature will be present in 0.9.9

Do members inherit the access rights of the group user?

Yes. Group membership is transitive (each member of a group receives the privileges granted to that group) and additive (if you are a member of several groups, each granted different privileges to the same resource, your effective privileges will include all of the privileges granted to any of the groups you are a member of.

So members of a 'resource administrators' group granted write access to a set of resources might also be members of a 'resource users' group which only has read access granted to it, and the administrators will receive read+write access as a result.

Do other group members gain access to my collections?

Group members will only gain access to your collections if you grant them access to your collections. They won't gain access by default. All access is granted either through explicit Grants by a collection or a principal, or through setting the default privileges on a collection or a principal.

Further Reading

Take a look at Permissions/Examples for some more examples of how to do particular things within the new permissions model, and look into Configuration/settings/default_privileges for details of setting the default privileges granted by new users.

What the Privileges Mean

The DAV permissions are as follows:

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

Some permissions are aggregate:

  • write - aggregate of write-properties, write-content, bind & unbind
  • all - aggregate of all permissions

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

Furthermore, with the approach of CalDAV Scheduling Extensions to WebDAV (draft) several further CalDAV permissions are added:

  • CALDAV:schedule-deliver-invite
  • CALDAV:schedule-deliver-reply
  • CALDAV:schedule-query-freebusy
  • CALDAV:schedule-send-invite
  • CALDAV:schedule-send-reply
  • CALDAV:schedule-send-freebusy

Two more aggregate permissions are also added with this RFC:

  • CALDAV:schedule-deliver - CALDAV:schedule-deliver-invite, CALDAV:schedule-deliver-reply and CALDAV:schedule-query-freebusy
  • CALDAV:schedule-send - CALDAV:schedule-send-invite, CALDAV:schedule-send-reply and CALDAV:schedule-send-freebusy

read

Grants basic read access to the principal or collection.

write-properties

Grants access to update properties of the principal or collection. In DAViCal, when granted to a user principal, this will only grant access to update properties of the principal's collections and not the user principal itself. When granted to a group or resource principal this will grant access to update the principal properties.

write-content

Grants access to write content (i.e. update data) to the collection, or collections of the principal.

unlock

Grants access to write content (i.e. update data) to the collection, or collections of the principal.

read-acl

Grants access to read ACLs on the collection, or collections of the principal.

read-current-user-privilege-set

Grants access to read the current user's privileges on the collection, or collections of the principal.

write-acl

Grants access to writing ACLs on the collection, or collections of the principal.

bind

Grants access to creating resources in the collection, or in collections of the principal. Created resources may be new collections, although it is an error to create collections within calendar collections.

unbind

Grants access to deleting resources (including collections) from the collection, or from collections of the principal.

CALDAV:read-free-busy

Grants other users the privilege to query my free/busy, via the CalDAV free-busy-query report.

CALDAV:schedule-deliver

These privileges will typically be granted wholesale within a small busines or workgroup environment, where everyone should be able to schedule meetings.

CALDAV:schedule-deliver-invite

Grants other users the privilege to deliver invitations to me.

CALDAV:schedule-deliver-reply

Grants other users the privilege to deliver replies to invitations I sent to them.

CALDAV:schedule-query-freebusy

Grants other users the privilege to query my free/busy, via the methods defined in the scheduling extensions to CalDAV.

CALDAV:schedule-send

These privileges will typically be granted by a person to their assistant, or to the people in their team, or direct manager, who might be expected to schedule meetings on their behalf. You would expect these to be granted along with the 'write-content', 'bind' and 'unbind' privileges.

CALDAV:schedule-send-invite

Grants other users the privilege to send invitations on my behalf.

CALDAV:schedule-send-reply

Grants other users the privilege to reply to invitations on my behalf.

CALDAV:schedule-send-freebusy

Grants other users the privilege to send freebusy queries on my behalf.

Notes

iCal Does Not See Granted Calendars

Apple iCal only sees delegations at the principal level, so if you are using iCal and you wish to grant access to only a subset of your collections it is necessary to first grant access by default to the principal, and then set narrower privileges on each individual collection which you want to restrict access to.

At present iCal will not see the calendar if you grant a default of restricted privileges at the principal level, and grant broader specific privileges to individual calendars.