[cosmo-dev] options to fix security hole

[Randy Letness]

> Jeffrey Harris wrote:
>>
>> One possible option C would be to not bother with read-only item 
>> tickets.  If I know a UUID, I can always add it to a collection, I 
>> just don't get edit access to it.  This seems like a reasonable 
>> approach to me.  I think it might give a smoother transition for the 
>> desktop and morse code:  everything would continue to work, but 
>> behind the scenes when morse code added items to multiple 
>> collections, those items wouldn't be editable.
>>
>> I think that might actually work reasonably well with existing 
>> Desktop code (although not perfectly) immediately if we made the 
>> server silently (or at least non-fatally) fail to process changes to 
>> read-only items. Existing desktop users would still change the item 
>> in question when they synced the read-write version, and they could 
>> still add items to new collections.
>>
>> There'd definitely be problems; user's who didn't have read-write 
>> access through some collection wouldn't know they didn't have 
>> edit-access but think they did.  Still, this seems better than 
>> requiring all desktop clients to upgrade immediately.
>
> This is a good idea and would make existing clients mostly backwards 
> compatible with the existing protocol, allowing all the work to be 
> done on the server.  We could always add support in the protocol for 
> determining permissions and tighten things up later.  One concern I 
> have is that both the desktop and webui may need some tweaking to 
> handle a read-write collection containing read-only items.  If we fail 
> silently then the clients will assume these items were changed, and if 
> all the clients have access to is the read-only version then we end up 
> with inconsistent data.  The bare-minimum we could do would be to add 
> an exception handler for both clients when this happens, letting the 
> user know they can't edit that particular item.

Ok heres what I have working so far:
i
1. Randy uses Chandler to publish collection A with item x
2. Randy shares collection A with Travis using read-write ticket T1
3. Travis subscribes to A using T1
4. Travis adds item x to his collection B
5. Travis syncs B, item x gets added to b read-only (because there is no 
way for Chandler to include T1 in the morse code request)
6. Travis updates item x, syncs B (since x is read-only in B, server 
silently ignores the update and proceeds as normal)
7. Travis syncs A (item x gets updated because x is editable in shared 
collection A).

The key points here are 5,6, and 7, which allow the current desktop to 
function as is with no security hole.  But this won't work for all 
cases.  Consider:

1. Randy uses Chandler to publish collection A with item x
2. Randy shares collection A with Travis using read-write ticket T1
3. Travis subscribes to A using T1
4. Travis adds item x to his collection B
5. Travis syncs B, item x gets added to B read-only (because there is no 
way for Chandler to include T1 in the morse code request)
6. Travis shares B read-write to Jeffrey using read-write ticket T2
7. Jeffrey subscribes to B  using T2
8. Jeffrey attempts to update item x in shared collection B...server 
fails silently because item is read-only and the update is essentially lost

So it seems like we really do need a way for the desktop to include 
associated read-write tickets in a morse-code publish/update request.  
This could be as simple as going through each item in the collection and 
pulling out the "ticket=blah" from each collection url and including 
these tickets in the morse code request.  Grant and Jeffrey, how much 
work would this be?  What kind of impact would this have on existing 
clients?  Do we not allow items to be added to multiple collections  
until users upgrade or do we do the read-only thing as described above?

-Randy