[cosmo-dev] options to fix security hole

[Jeffrey Harris]

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