[Sum of Talk with Randy] Re: [cosmo-dev] options to fix security hole

[Mimi Yin]

After chatting with Randy on the phone, here is my understanding of  
how the security hole is going to be patched :)

Today, the server is happy to assign read-only *and* read-write  
tickets to new collections, even if the items in those collections  
already exist on the server and the user publishing this new  
collection is neither the original 'creator' of the items; nor  
received the items via a read-write share. In other words, the user  
got a hold of the items via a read-only share and by virtue of re- 
publishiing them in a different collection, is able to gain read-write.

In the new world, the server will only assign read-write and read- 
only tickets to a new collection if ALL the items in the collection  
are either entirely new (do not already exist on the server and  
therefore were created by the publisher) OR already come with read- 
write tickets.

This involves changes to both the server *and* the Desktop client  
which will now have to understand about individual items inheriting  
tickets from the collections they are a member of.

What is the short-term fall out of this change?

1. You can't put items you received via Email on the Server.

In the new world, items you receive via Email will fail to be added  
to the server if they are included in collections that are on the  
server. This is because emailed items don't include a read-write ticket.

Will log bug.

2. You might experience some Phantom Sharing.

We will continue to have Phantom Sharing where users who have not  
established explicit sharing relationships via shared collections  
will be mysteriously editing each other's items because they both  
came by read-write tickets to those items. How could this happen?

- User-A publish Collection-A and shares it with RW Ticket-A with  
User B.
- User-B adds items from Collection-A into Collection-B and shares it  
with RW Ticket-B with User C.
- Users A and C are sharing items by virtue of User B, but A and C  
never established an explicit sharing relationship and don't know  
each other. (On the other hand, User A *could* just be another person  
User B shared Collection-B with. User C has no way of knowing who  
User B shared Collection B with.)

A weirder scenario might be:
- User-A publish Collection-A and shares it with RW Ticket-A with  
User B.
- User-B adds items from Collection-A into Collection-B and shares it  
with RW Ticket-B with User C.
- User-C adds Collection-A items from Collection-B to their own  
Collection-C and publishes Collection-C to the server.
- User B unpublishes Collection-B, but the items that were also in  
Collections-A and C don't get removed from the server.
- User-C and User-A are *still* sharing some items and User-C  
occasionally sees that someone named User-A is editing items in  
Collection-C. This might be odd if User-C knows they haven't shared  
Collection-C with anyone else and is no longer sharing Collection-B  
with User-B.

Will log bug.

3. You won't be able to add read-only items to other collections on  
the server.

Today, the Desktop allows you to add items from read-only collections  
to other collections, but won't let you edit those items. The Server  
will also happily accept read-only items that show up in other  
collections. Once the Server has done that, the web UI allows you to  
edit those read-only items because the Server has no idea that  
they're read-only, even though the Desktop does.

In the new world, this will no longer work. The Server is going to  
reject read-only items that show up in other collections. Ultimately,  
we would like to make this work, but for now, we're just going to  
keep track of it as an issue.

Will log bug.

The 3 issues above I think are things we can 'live with' in the short- 
term as we test out Randy's rather significant changes and  
improvements to what we have today. I think they are mostly edge  
cases, but we should address them sooner rather than later if they  
turn out to be more common than we expect.

The only thing I think we might want to fix in parallel with Randy's  
changes is to amend EIM so that we distinguish between item that have  
been manually (via Drag and Drop) added to another collection versus  
items that were automatically picked up by a rule and added to one of  
the Out of the Box collections.

I think this is important because when users delete collections from  
the Server, the Server is only going to delete items that *only*  
exist in that one collection. This will be the surest way for users  
to 'revoke access' to items they no longer want in circulation.

However, given that all messages are automatically added to the In/ 
Out collections and all collections (unless otherwise specified) have  
all their items added to the Dashboard collection, assuming the user  
has published their Out of the Box collections to the Server,  
deleting collections from the Server won't actually delete their  
member items off the Server (even though locally, the Desktop will  
know to delete them from the Out of the Box collections).

Basically, we might end up with entire collections' worth of  
'homeless' items that belong in no collections, but exist on the  
Server anyway. Does anyone else have thoughts about whether this is  
something we should fix in the short-term?

Will log bug.

Would it be productive to have a meeting with Randy and Grant to  
review these issues on the phone?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20080221/036a7a1a/attachment.html