[edit] Store ACLs

Access controls are enforced within the store. In order to understand the information contained here, you'll also want to consult Guides/Store Protocol.

This needs to be thoroughly checked over; it's generally right, but not sure about all the details :)

[edit] Theory

Within the store, permissions are more akin to an SELinux or Windows-type system than a traditional UNIX system. This is for a variety of reasons, but primarily allows fine-grained and flexible permissions to be setup on the system, including users we don't even know about (e.g., if you share your calendar with a non-Bongo user by giving them a password, the control is "Allow the user with <e-mail address> to read this file if they supply <this passowrd>")

These permissions are stored as properties of documents in the store, like any other property, but are enforced by the store itself - if you log in as a user that doesn't have permission to access a certain file, there should be no way of getting it.

[edit] Practice

First, since these are simply properties, we can read and write them using the PROPGET and PROPSET commands respectively. Such a command might look like:

 PROPGET /mail/inbox/something nmap.access-control

This property is a simple string, with roughly the following grammar:

 <access-control-list>  ::= <access-control> [<access-control-list>]
 <access-control>       ::= <action> ' ' <who> ' ' <privilege> ';' 
 <action>               ::= 'grant' | 'deny'
 <who>                  ::= 'user:(user)' | <token> | 'all' | 'auth'
 <token>                ::= 'token:pw:(user):(password)' | 
                            'token:email:(address):(password)

(Ignoring for now the actual privilege - see the list below)

So, some examples of ACL lists might be:

 grant all read;
 
 grant all read; grant user:admin all;
 
 grant token:email:mickey@example.com:minnie read;

Which are hopefully reasonably self-explanatory.

The full list of privileges is:

• all (all privileges :)
• read
• write
• read-props (applies to properties _except_ nmap.access-control ?)
• write-props
• read-acl
• write-acl
• read-own-acl
• bind (COPY, MOVE, WRITE when replacing)
• unbind (DELETE, MOVE, RENAME, REMOVE)
• list (LIST collections, CALENDARS, EVENTS)
• unlock (unused in store)
• read-busy (unused in store, bug)

So, in order to successfully execute a MOVE, you need both bind and unbind privileges on that document.

[edit] Future

Ideally we'll have not just users but groups of users also (e.g., for administration, that kind of thing?). Rather than have to add each user to each ACL we're interested in, it would be nice to extend the ACLs so that we could say something like:

 grant all read; grant group:admins all;

Also, I don't think privileges can be grouped: e.g., you can't do something like:

 grant group:powerusers read,read-acl,read-props;

(Or something; it's a bit contrived). We can do the same thing by having many rules, but... well.