[sugar] Importing objects from journal

[Bert Freudenberg]

Hi Michael,

To check my understanding I'll paraphrase - if an activity was  
granted the P_DOCUMENT cap then it can modify existing documents in  
the datastore, but it only ever gets access to them by explicit user  
interaction. The P_DOCUMENT_RO cap does not require user interaction,  
but only grants read-only access. Correct so far?

So ... P_DOCUMENT is independent from the saving of my activity  
instance in the datastore, I assume? But for now, there is only a  
single datastore API. Will that change?

Also, does P_DOCUMENT imply I can create arbitrary datastore entries?  
Will the dialog support creation of new documents?

And P_DOCUMENT_RO restricts access to certain document types - could  
a multi-media authoring tool request more than one type (we'd like to  
be able to mix text/image/audio/video)? And according to the bitfrost  
spec this conflicts with supporting streaming media, correct?

Thanks - this doesn't sound unreasonable after all ;)

- Bert -

On Sep 25, 2007, at 20:55 , Michael Stone wrote:

> Bert,
>
> Thanks for bringing this up: we are finally in a position to be  
> able to
> address your needs. I have set up a ticket (#3801) to track the  
> security
> implications of this discussion. Please feel free to update it as our
> design progresses.
>
> The overall summary of my security position is that, as an activity
> author, you should have to make exactly one call to Sugar to  
> request the
> user to select some documents for you to edit and you should have to
> make exactly one (different) call to Sugar to request read-only access
> to a collection of files described by a given query. The result of  
> these
> calls will contain a description of a set of files for you to open,  
> and
> perhaps some other information to be decided by further discussion.
>
> My basic feeling is that the calls should return a path to a directory
> containing your files on success and should return nothing on failure.
> However, we make no promises about what files you'll actually find
> inside the provided directory.
>
> Thoughts, feedback, and questions desired.
>
> Michael
>
> ---------------------------------------------------------------------- 
> ----
>
> P.S. - Here is a rough description of what we want those calls to do.
> Perhaps it will be helpful in explaining the security requirements on
> this API.
>
> According to the Bitfrost spec [1], activities must be isolated  
> from the
> Datastore in order to protect the confidentiality and the authenticity
> of the user's data. Furthermore, the isolation from the Datastore
> imposed on activities should broken only by exercising the  
> P_DOCUMENT or
> P_DOCUMENT_RO capabilities.
>
> Requirements:
>
>   o Activities MUST be able to access objects stored in the  
> datastore ONLY
>     by exercising the P_DOCUMENT or P_DOCUMENT_RO capabilities.
>
> When exercising the P_DOCUMENT capability:
>
>  1. an activity MUST direct Sugar to ask the user which documents to
>     provide.
>
>  2. Sugar SHOULD query Rainbow to learn whether the activity is
>     permitted to make the request.
>
>  3. If Sugar believes the request will be permitted, sugar MUST query
>     the user to learn which documents the user wishes to provide to  
> the
>     activity.
>
>  4. Sugar SHOULD direct Rainbow to make the selected documents  
> available
>     under the P_DOCUMENT capability.
>
>  5. Rainbow SHOULD provide the documents to the container associated
>     with the activity instance requesting the documents.
>
>  6. Rainbow MUST notify Sugar of the outcome of the transaction.
>
>  7. Sugar MUST notify the activity of the outcome of the transaction.
>
> When exercising the P_DOCUMENT_RO capability,
>
>  1. the activity MUST indicate its intention to exercise the  
> capability
>     to Sugar.
>
>  2. Sugar SHOULD query Rainbow to learn whether the activity is
>     permitted to make the request.
>
>  3. if Sugar believes the request will be permitted, Sugar SHOULD  
> query
>     the datastore for a list of documents to provide, read-only, to  
> the
>     activity.
>
>  4. Sugar MUST then direct Rainbow to make the the documents available
>     under the P_DOCUMENT_RO capability.
>
>  5. If the requesting activity has the P_DOCUMENT_RO capability,  
> Rainbow
>     SHOULD make the supplied documents available to the activity's
>     container in a read-only fashion.
>
>  6. Rainbow MUST notify Sugar of the outcome of the transaction.
>
>  7. Sugar MUST notify the activity of the outcome of the transaction.
>
> References:
>
> [1]: http://dev.laptop.org/git? 
> p=security;a=blob;f=bitfrost.txt;hb=HEAD
>
>
>
> On Tue, Sep 25, 2007 at 01:48:55PM +0200, Bert Freudenberg wrote:
>> What's the policy on accessing objects in the journal?
>>
>> I see Write uses sugar.graphics.objectchooser which simply queries
>> the datastore. Will that work once security is enabled?
>>
>> Can I then store the retrieved object id in my activity instance and
>> keep that reference? Can I re-open that external object after
>> resuming my activity? Can I track changes to the object in this way?
>> How do I let the datastore know that my activity contains a reference
>> to another object, so that the other would not get discarded?
>>
>> Or do I have to copy and keep that copy in "my" datastore entry,
>> which given the limited amount of NAND would be highly undesirable?
>>
>> - Bert -