Shared File Store Access Control

I spent the morning reading about WebDAV ACLs and investigating how to configure them in Slide. Now I'm trying to figure out what the default privilege set should be for the Chandler Server's shared file store.

Each user is given a home directory within the shared file store. Should each resource in a user's homedir be publicly viewable unless the user denies read access? Is that for any user in the world, or just for any user authenticated to the server (in the case where all users on the server are part of a single workgroup)?

Should somebody be able to examine the root of the shared file store and generate a listing of all home directories on the server? Again, everybody, or just members of certain groups?

At what granularity should a user be able to assign write permissions - entire homedir? individual collection? individual resource? should we handle specific data types (calendar, bookmarks, RSS subscriptions) differently?

What other access control issues can we think of?

I'm leaning towards making all data as public as possible, letting the individual decide if a specific resource should be private (denying read privilege to "all" or specific users and/or groups). Write privilege on any resource will have to be specifically granted by the owner to users and/or groups (obviously the owner of a homedir will have write permission on the homedir by default). I'm open to any other strategies though. Let's hear them.

Here's my strawman for permissions:

• Read permission: Everything should default to being readable to those who are authenticated. For enterprise, university and even workgroup use cases, this should allow people to read each others' calendars by default.
• View-free-busy permission should default to being publicly allowed.
• Write permission should default to being only the owner.

--Lisa

Hmm.. why deny read access to unauthenticated users? this means that i wouldn't be able to use the server to publicly share my calendar with my friends unless i gave them my credentials or made accounts for them.

Well, the client can always open up permissions using an ACL request (grant read to all) for a "public" share. I wouldn't mind starting out with the default of making everything public, but that's not the design as it stands. Check out some of the older Wiki pages about "sharing circles" and how originally shared information would only have been available to Chandler users in your sharing circle -- we're already widening that to include other non-Chandler users in the same org. However, we'll clearly want to run this by design because the network architecture is still causing some fallout in the shape of changes in the design.

Then in the longer run there's tickets.

--Lisa

-- BrianMoseley - 23 Feb 2005