[Cosmo-dev] Re: securing access to items in multiple collections

[Morgen Sagen]

On 9/28/07, Brian Moseley <bcm at osafoundation.org> wrote:
> On 9/28/07, Morgen Sagen <morgen at osafoundation.org> wrote:
>
> > What are we trying to solve with tracking which collection a
> > republished item was copied from?  In the scenario where the client
> > copied from A to C, you're saying that should fail, but copying from B
> > to C should succeed (correct me if I am misunderstanding this).  Why
> > shouldn't that succeed in either case?
>
> i think we should be designing the server and the protocol to lock
> down access to items as tightly as possible. among other things, i
> think that means the permissions on the source collection are more
> important than the permissions on other collections an item
> incidentally happens to be a member of, and that those source
> permissions should move with the item when it's copied into a
> destination collection. this "deny, then allow" policy is more
> conservative and, i think, safer than the opposite.

I guess my point is that if you are relying on the client to let the
server know which items the client *shouldn't* have write access to, a
devious client will not fess up to having only read-only access.

> >  If we cause the A to C copy to
> > fail, the user is going to try again by copying from B to C.  Simply
> > put, the user has write access to the item because they can just go
> > edit/sync the copy in B.
>
> that is technically true. it seems to me that there's a problem in the
> mental model of how the user has organized his data if he has put an
> item in two collections and given the same collaborator read-only
> access to one collection and read-write access to another. there is a
> flexibility versus security trade-off, and i'd prefer to err on the
> side of security. but maybe i haven't been presented with a compelling
> scenario that makes this all seem reasonable.

Actually, I don't think this scenario is all that unusual.  Say I have
my own "Work" collection where I keep my tasks and I share with you
read-only, and we both share read-write access to the "Office"
calendar.  As soon as I copy an item from Work to Office (so that
others can work on this task), and you want to add this item to your
Work collection (so it appears in your task list), you are now in the
described situation.  I still contend that it shouldn't matter whether
you copy the item from my Work colllection or the Office calendar
(because you have write access to the item via the Office calendar),
but I would like to get input from design on this.  Mimi?

> > I agree sending the ticketed url for a published collection is
> > strange, but how else would someone ever copy an item from one of
> > their own collections to a collection they subscribe to?  When the
> > client syncs that other collection they're not using basic auth, just
> > the ticket for that other collection, so there would need to be some
> > way to let the server know that the client does have write permission
> > for the item.
>
> good point.
>
> you didn't address my point about having my eim processor independent
> of my protocol handler. would it be reasonable to find a way to
> specify tickets in the eim recordset collection, not in the request
> headers (either as part of the entire eim collection, as per your
> suggestion, or with each individual recordset, as per mine)? they
> could be specified as (ticket-key, collection-uuid} pairs rather than
> urls.

I didn't address this because we're still spec'ing out the user level
requirements, and your question assumes item-level ticket association,
which I haven't yet seen a use-case for.  Again, if the client can lie
to the server about an item's source collection, what's the point?