[cosmo-dev] options to fix security hole

[Randy Letness]

We had a long chat about this yesterday on #cosmo and I've been thinking 
about this a while, and there is still no easy solution.  So the problem 
again:

http://chandlerproject.org/Journal/CosmoAccessControlNotes#Whats%20the%20problem?

For the longest time I've thought that the best solution to this was to 
go back to storing copies of items in multiple collections.  We'll call 
this "option A" See:

http://chandlerproject.org/Journal/CosmoC18NNotes

The main advantage of this is that there will be little protocol work, 
no desktop work at all, and only minor webui work, and it solves the 
security problem. The disadvantage is that we now have copies of items, 
which the desktop handles well, but any other client would require a lot 
more work either on the client or server to bring the functionality to 
that of the desktop.  Since there is going to be little to no work on 
the desktop and most of the new work is moving to the web, this may not 
be the best approach as it is a "quick fix" and will require another 
round of thinking down the road when the web widgets need to do more 
advanced stuff.

So I started thinking about other options to close the security hole and 
still keep the "item soup" that the server implements now. Another 
option (option B) would be to store permissions for each item in a 
collection on the collection itself.  So for each item added to a 
collection, the relationship also contains what type of access that 
collection has to that item.  This allows collections to contain items 
with different permissions and for an item to have different permissions 
in different collections.  So the workflow would look something like:

1. randy creates collection 1
2. randy adds new item A to collection 1 --> collection 1 now contains 
an entry for item A for write access because its a new item added to his 
collection
3. randy shares collection 1 using read-only ticket T1 to travis
4. travis adds item A to his personal collection 2
5. when travis syncs collection 2, the request includes item A plus 
ticket T1
6. the server adds item A to collection 2 --> collection 2 now contains 
an entry for item A for read-only access because the ticket provided 
granted read-only access to item A
7. travis attempts to update item A through collection 2 --> server 
denies access because although he has write access to the collection, 
item A is read-only
8. travis shares collection 2 to mimi using read-write ticket T2
9. mimi adds item A to her collection 3
10. when mimi syncs colleciton 3, the request includes item A plus ticket T2
11. the server adds item A to collection 3 --> collection 3 now contains 
an entry for item A for read-only access because although the ticket 
granted write-access to collection 2, item A is read-only in collection 2

So I think this should work.  Well 85% sure.  Plus we don't have the 
problem of synchronizing copies and the webui should just work as is.  
Also, the migration work won't be as bad.

Heres the catch: 

This implies some desktop work, which would be to keep track of all 
tickets for shared items and to included those tickets in the morse code 
update request.  If a valid ticket is not found when adding an existing 
item to another collection, the request would be denied,  There is still 
the problem of "uuid hijacking", meaning someone could theoretically 
publish your uuid before you, but the chance of that is unlikely.  Once 
your item is published, anyone else will get "access denied" if they try 
to publish the same uuid without a valid  ticket.

I'm leaning more towards option B, and although it will require some 
desktop work, it will prevent a lot of hassle down the road.

Thoughts?  Other ideas?  Do I see an option C?

-Randy