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