[sugar] Importing objects from journal

[Michael Stone]

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 -
> 
> 
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar