[cosmo-dev] options to fix security hole

[Mimi Yin]

+ What about the case where Randy receives item 1 via both  
collections A and B?
- Randy was granted read-write access to collection A and read-only  
access to collection B.
- The client needs to logic to know to give Randy read-write access.

+ The same is true if Randy create collection B. Another subscriber  
or Randy creates item 1. Then that subscriber adds item 1 to  
collection A and shares A with Randy with a read-only ticket. Randy  
should still have read-write access to item 1.

+ However, if Randy receives item 1 via a read-only ticket for  
collection A and then adds item 1 to collection C which he has read- 
write access to it, read-only wins and he shouldn't be able to edit  
item 1.

Basically, I think there also needs to be an idea of whether a user  
has 'explicitly' granted read-write access to an item versus  
'implicitly' granted read-write access (which should be denied) by  
virtue of personally adding that item to another one of their  
collections.

Jeffrey does what you're describing below mean that if you receive an  
item only via Email and then you publish it the server, you won't be  
able to edit anymore? Or could we still do some selective silo-ing on  
the server to prevent that from happening?

Mimi

On Feb 6, 2008, at 3:09 PM, Jeffrey Harris wrote:

> Hi Randy,
>
>> 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?
>
> Travis and I talked about this a little while today.  Let me see if  
> what I'm thinking (based on what Sam Halliday was suggesting on IRC  
> yesterday) is what you're thinking:
>
> There are collection tickets, and there are item tickets, each in  
> edit or read-only flavors.
>
> If I have an edit ticket to a collection, I can add/create items in  
> that collection, but it doesn't automatically grant me edit access  
> to all items in the collection.
>
> Having edit access to a collection gives me access to that  
> collection's "item-edit ticket list" (this implies item tickets are  
> associated with one item, but potentially many collections).
>
> If I have write access to collection A, I can create item Foo in  
> it. When I do this, read-only and edit tickets are created for that  
> item, call them ReadItemTicket1 and EditItemTicket1.   
> EditItemTicket1 is added to collection A's item-edit ticket list,  
> and now anyone with edit access to collection A can edit Foo.
>
> If I give Randy read-only access to collection A, he gets a read- 
> only ticket for item Foo.  So if Randy has an edit ticket for  
> collection B, he can add Foo to collection B with ReadItemTicket1,  
> and ReadItemTicket1 is then associated with collection B, but *not*  
> EditItemTicket1, so other people with edit access to collection B  
> can't edit Foo.
>
> Does that match up with what you're suggesting?
>
> ------------------------
>
> 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.
>
> Sincerely,
> Jeffrey
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev