[cosmo-dev] options to fix security hole

[Randy Letness]

Mimi Yin wrote:
> Here's a much more complicated solution...
>
> + When a collection is deleted on Chandler Hub or unpublished from 
> Chandler Desktop, only delete items that have *not* been manually 
> added to other collections

This is how it works today on the server.  If an item was added to 
another collection, then that item will not be removed.  An item is only 
deleted if it only exists in a single collection, and that collection 
was deleted, or if it only exists in a single collection and the item 
was removed from that collection.


> + However, *do* revoke all tickets associated with that collection 
> which results in the following:
> - (T1) Users who *only* have access to items in the 
> deleted/unpublished collection by virtue of that collection will lose 
> that access - Do the items get deleted for these users?

These users will lose access to the items if they are accessed through 
the deleted collection because the ticket is no longer valid and the 
collection doesn't exist.  If the items were added to other collections, 
the items are still present, but require a different ticket/user to 
access them.


> - Any users who are 'downstream' of the T1 users also lose access to 
> items in the deleted / unpublished collection - Is this possible?
>

This is possible, and is the complicated solution I described.  The 
server would basically have to store a "chain" of tickets each time an 
item is added to a collection.  For example. 

1. User A publishes item X in collection 1, shares with rw ticket T1 (no 
ticket stored with this)
2. User B adds item X to collection 2 using rw ticket T1, shares with rw 
ticket T2 (T1 stored with this)
3. User C adds item X to collection 3 using rw ticket T2 (T1, and T2 
strored with this)
4. etc/etc

Now if User A or User B unpublishes their collection, User C would lose 
access to X because in order for User C to have access to X, both T1 and 
T2 must be valid.

This is a lot more work than was planned (implementation, testing, 
migration), so we need to decide if its worth supporting.  One option is 
to do the basic security fixes now(fix the know the uuid/gain read-write 
access problem), and implement this later so that we can move on to 
other things.  Or we could spend time on this now, but there is still 
the case of existing items that were added to multiple collections.  
These items don't have any "ticket chain" and can't really be controlled 
by revoking a ticket.

> *Question:* What if you gained access to the same items by virtue of a 
> different collection? Are there any situations where you might be able 
> to hold on to your access? Here's an example:
>
> 1. User A publishes a collection and shares it with Users B and C with 
> Ticket A-B.
>
> 2. User B adds some items from that collection to a different 
> collection and shares that second collection with User C with Ticket B-C.
>
> 3. User B unpublishes the 2nd collection, thereby revoking all Ticket 
> B-Cs.
>
> Can Users A, B and C still see the items that User B manually added 
> from the 1st collection to the 2nd collection by virtue of Ticket A-B?

Yes because the item still exists in the first collection.  Now any item 
that User B adds from the 2nd collection to the 1st collection  using 
Ticket B-C would be removed.

-Randy