Previous Notes | Next notes

Rationalizing Permissions

This research compares ACLs from various Internet repository access protocols that Chandler could support in the future, to see if there's a way to remain compatible with most or all of them.

IMAP

In general, IMAP4 ACL (RFC2086) has very mailbox-oriented permissions -- for example, users can either see or change anything in the mailbox, or users can see or change nothing in the mailbox.

Interoperability with IMAP ACLs could have two goals.

• A Chandler repository could act as an IMAP server, potentially allowing a user to read their mail remotely. In the Westwood timeframe, the Chandler repository could actually reside on a server with high availability. The repository's expression of ACLs could be exposed as IMAP ACLs so that the user can not only read their mail remotely through IMAP, they can also have some control over permission. Unfortunately, I don't see this model as very realistic. The IMAP permission model is too limited (only mailboxes have ACLs, not individual items) and so the ability to set ACLs through IMAP is not very useful. It's better if the Chandler repository does not support IMAP ACLs even if it supports IMAP, and simply use the underlying repository ACLs to grant or deny permission to operations without exposing information about permissions over the protocol.
• A Chandler repository could act as a client to a standards-based IMAP server, and use the IMAP ACLs extension to manage permissions. This could work if IMAP servers implement the ACLs extension well. However, we don't know yet how well ACLs is supported by general IMAP servers. Note also this could be confusing to users because managing permissions of the IMAP mailbox on the server might have to be done very separately from managing permissions of local shared Chandler content -- again, the IMAP model is just too limited for code to be able to automatically interpret Chandler repository ACLs and translate them into some ACL that is valid on the IMAP server. So, if the models are too different to be automatically combined, I suspect this feature has too little value to be done any time soon.

The IMAP permission model is explained a little more in the sections on individual rights for the sake of completeness and making comparisons. Note that a server implementation can tie rights together. This helps implementing compatible servers because the write flags permissions can be combined if necessary to make compatible with WebDAV and NFS. However, it makes it much more difficult to write a client that can upload a file and then set ACLs that are consistent with the local ACLs.

WebDAV

WebDAV ACLs were specifically designed to be compatible with those defined by both NFS and NTFS, so it should be easy to satisfy all those. Resources (including collections) have a set of rights that can be granted. Servers may support denying rights as well. There's a very basic hook into ACL inheritance which may be usable.

Interoperability with WebDAV ACLs could have a bunch of goals:

• A Chandler repository could be a native WebDAV repository, using WebDAV to allow browsing by non-Chandler clients, and possibly even browsing and sharing by other Chandler clients. This means acting as a WebDAV server, which requires mapping the native repository ACLs very accurately to ones allowed by the protocol.
• A Westwood server could be a WebDAV server, allowing access to all kinds of items (mail, contacts, calendar items) over a single protocol. This has serious advantages over supporting different protocols for the different kinds of items, and one of those advantages is consistency of ACLs.
• A Chandler client could act as a WebDAV client, publishing some of a repository (or backing up all of a repository) to a WebDAV server. In this publishing process, the Chandler client could attempt to rationalize server permissions with local sharing permissions.

Note that WebDAV allows aggregating permissions. For example, if Chandler sees no reason to have "read-current-user-privilege-set" granted separately from "read" privilege, then "read" privilege can grant the other implicitly.

NFS v4

NFS has Access Control Lists that are very specific and easy for clients to work with because they must behave the same on all servers, including what list of rights is available and how ACLs are processed. Unfortunately this can make it harder for servers to implement in a compliant way if the server's internal model doesn't match.

I'm not sure that NFS compatibility is that interesting to Chandler. Would Chandler users have access to NFS servers to backup or export Chandler content? If so, then files would likely be saved locally or to a mounted drive, without Chandler having to support NFS. I'm not sure how saving locally or to a mounted NFS drive would persist permissions, however.

Read permissions

IMAP4 includes two separate read permissions. One allows users to see that the mailbox exists. The other allows all other read permissions within that mailbox (ability to do LIST and SUB inside that mailbox).

WebDAV includes the permission to read resources or collections, where the ability to read a collection consists of the ability to list its children and to read unhidden properties.

NFS has read_data, read_attributes and read_named_attributes, thus attributes are grouped into named and regular. There's also a separate permission to list the contents of a directory. It's not clear what it means to have read_data permission on a directory or if that's even possible.

Write permissions

IMAP4 has some granular write permissions (but still only at the level of mailboxes).

• write seen/unseen flags. This permission is probably restricted only to the main user of the mailbox.
• write all other flags.
• insert a new document.
• create sub-mailboxes.
• delete an item (mark deleted) or expunge

WebDAV has

• write-content -- PUT or otherwise change a resource body, or if it's a collection, change its membership list
• write-properties -- write the properties of this resource, PROPPATCH
• bind -- add a new member to a collection
• unbind -- remove a member from a collection, which may delete it

It also names the "write" permission which aggregates both these.

NFS has

• write_data (maps WebDAV write-content)
• write_attributes and write_named_attributes (together these map to WebDAV write-properties)
• add_file and add_subdirectory (together map to WebDAV bind)
• delete_child applies to all children
• delete applies to self

Administer rights

IMAP4 has only a SETACL privilege in this area. Presumably this affects the ability to read ACLs as well.

WebDAV has both get-acl and set-acl, and a special unlock privilege for principals other than the lock owner to be able to revoke locks. There's also the utility "read-current-user-privilege-set" which allows the user to see only their own permissions. This might be aggregated under normal "read" permissions rather than be a separate permission.

NFS has read_acl, write_acl and write_owner.

-- LisaDusseault - 09 Apr 2004