[cosmo-dev] options to fix security hole

[Mimi Yin]

I had 2 nightmare about this and I think I now have a bit more  
clarity on what the issues are:

If when we delete a collection from Chandler Hub, we also delete all  
the items in that collection, this behavior will be in conflict with  
how the Desktop works. So we can do the following:

Change the Desktop so that it also deletes all items in an  
unpublished collection regardless of whether any items were manually  
added to other collections. But I'm worried about the ripple effect  
of deleting items....

Here's a much more complicated solution...

+ Add a 'flag' on items when they've been 'manually' added to another  
collection (as opposed to automatically added to the Dashboard  
collection because the collection is included in the Dashboard)

+ 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

+ 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?
- Any users who are 'downstream' of the T1 users also lose access to  
items in the deleted / unpublished collection - Is this possible?

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?

Mimi

On Feb 19, 2008, at 4:17 PM, Randy Letness wrote:

> Mimi Yin wrote:
>> + Could an item 'inherit' a new ticket from another read-write  
>> collection? OR
>
> Thats currently what happens when an item is added to another  
> collection, it essentially inherits the tickets from the collection.
>
>> + Could the server selectively *not* delete tickets for items that  
>> are also in other collections?
>
> Tickets are issued on a collection basis currently.   So when a  
> collection is deleted, the tickets are deleted, otherwise they  
> would be in limbo.
>
>> Currently, ff we don't remove the item, what happens? Can anybody  
>> edit the item?
>
> Anyone with access to a collection that the item is in can edit the  
> item.  So for instance:
>
> 1. I publish collection 1 with item A
> 2. You subscribe to collection 1 using ticket T1
> 3. You add A to your collection 2, and sync collection 2 (item A is  
> now in collection 1 and collection 2)
> 4. I unpublish colleciton 1 (ticket T1 is removed because it was  
> assigned on collection 1, item A is removed from collection 1 but  
> still exists in collection 2)
> 5. You update item A using collection 2.
> 6. You can share item A using tickets generated from collection 2
>
> Thats currently the way it works, which is once you share an item  
> and that item is added to other collections not owned by you, you  
> essentially have no control over it.
>
> An alternative approach would be:
>
> 1. I publish collection 1 with item A
> 2. You subscribe to collection 1 using ticket T1
> 3. You add A to your collection 2, and sync collection 2 (item A is  
> now in collection 1 and collection 2)
> 4. I unpublish collection 1 (ticket T1 is removed because it was  
> assigned on collection 1, item A is removed from collection 1 and  
> collection 2 because T1 was used to add A to collection 2)
>
> -Randy
>
>
>
>
>
> -Randy
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20080220/4c5b7b37/attachment.html