[sugar] datastore use cases for activities

[Tomeu Vizoso]

On Wed, 2007-09-26 at 18:01 -0400, Michael Stone wrote:
> Note: I am going to completely ignore rate-limiting in the following
> analysis.
> 
> > == Activity session stops ==
> > 
> > When an activity session stops, we want to store its state to the
> > Datastore so it can be examined later from the journal and it can be
> > resumed from where it was stopped.
> 
> No security impact.

Well, I guess someone should assure that this activity is:

- updating the object that it created if running for the first time, or
- updating the object it resumed from.

I guess Sugar should inform Rainbow that this activity has permission to
update that object ID, and the datastore would check that permission
before actually updating the data.

This is needed to protect data integrity.

> > Activities need to at least save to the journal an entry with the
> > activity session title, the buddies that participated on the activity
> > session, an image that visually represents the state of the activity (a
> > screenshot, currently), any tags that can help in categorizing the entry
> > and the activity-dependent data as metadata properties or a file on
> > disk. If the data in the file can be interpreted by other activities,
> > the 'mime_type' property should be set.
> 
> No security impact.
> 
> > For some activities like Record that wish to expose some products of the
> > activity session like in this case photographs, videos or audio
> > recordings, a journal entry for each of those can be created, specifying
> > the right mime type for each of them. In this way, a photograph can be
> > modified in Paint, a video watched in Watch&Listen, or an audio
> > recording imported in one of the TamTam activities.
> 
> With reference to my recent emails, I don't think there's a security
> impact here. However, if further clarification is needed, let me know
> and I'll attempt to provide it.
> 
> > == Activity automatically saves its state ==
> > 
> > At any point during the activity session, the activity can judge
> > necessary to update the entry in the journal. In this way the journal
> > can show the state of currently running activities and in case of a
> > crash the work is not lost.
> 
> No security impact.

See above, the activity should only be able to update the entries that
pertain to that particular session, no entries from other session or
activities.

> > == User presses 'Keep' button in a running activity instance ==
> > 
> > Same as in the two previous use cases, only that in this case, any
> > future saves will be done in a new entry. The current one is preserved
> > in the journal as frozen so it can be resumed later in a new activity
> > session. This acts similarly as branching in a vcs.
> 
> No security impact.

Same as above, update permissions need to be checked.

> > == A Journal entry is resumed ==
> > 
> > The activity is started by the journal and an object id corresponding to
> > the resumed entry is handled to it.
> > 
> > The activity will retrieve from the datastore the metadata for that
> > object id and the file were data was stored.
> 
> ... I need to know more about how this actually works to judge the
> security impact. The important thing is that activities must not be
> granted access to user documents *simply because they know the object's
> IDs*. Instead, each time they run, they must explicitly be granted
> access through the mechanisms previously described: i.e. by being
> resumed, by exercising P_DOCUMENT, or by exercising P_DOCUMENT_RO.

In this case, the journal knows the user wants to resume that particular
object id in that particular activity. So Sugar could tell Rainbow that
this activity session should have permission to read and update that
concrete object. No further action should be required from the user.

> > In cases like Record, querying the datastore by 'activity_id' will
> > retrieve the separate entries that make part of this activity session
> > (photographs, videos and audio recordings).
> 
> See above.

This is trickier, if the user is requesting that Record is launched for
resuming the entry 123, Record needs to be able to read and update the
entry 123 plus all the other entries that pertain to the same session
(with the same 'activity_id').

> > == User presses 'Insert image' button in a running activity instance ==
> > 
> > The activity requests sugar that the user should choose a journal entry
> > of the type Image (or several).
> 
> Instead, I think this should be something like "User presses
> Sugar-provided 'Insert Item' button, selects some documents, the
> documents are provided, and the activity is notified".
> 
> > After the user has chosen one or several entries, the dialog is closed
> > and the activity receives the object ids for those entries. Then it can
> > request the metadata or files for any of them.
> 
> If you really want to have the activity talk directly to the DS, then it
> is a security requirement that the DS delegate access-control checks to
> Rainbow.

Yes, we would prefer if activities talked directly to the DS using the
existing API.

In this case, the activity would request to Sugar that an object chooser
dialog is shown to the user, perhaps with some filter preset. After the
user chooses one or several files and dismisses the dialog, Sugar tells
Rainbow that the activity has permission to _read_ those objects. The
activity can request later those objects to the DS and the DS will check
with Rainbow if the activity can access those objects.

> > A similar use case would be for the upload file dialog in Browse. In
> > this case all entries that have an associated file should be presented
> > to the user. The user should be able to search, filter and sort just
> > like in the journal in order to find the entry that will be uploaded.
> 
> Activity-provided file selection boxes are explicitly not supported by
> the current Bitfrost spec. 

No "Activity-provided file selection boxes" are planned to be used by
activities. Browse will use exactly the same mechanism as in the "Insert
image" button, just that in this case no filter will be preset.

Tomeu