#3801 NORM Untriag: Rainbow, Sugar, and the Datastore need to integrate to isolate Activities from the Datastore

[Zarro Boogs per Child]

#3801: Rainbow, Sugar, and the Datastore need to integrate to isolate Activities
from the Datastore
---------------------+------------------------------------------------------
  Reporter:  mstone  |       Owner:  jg                                            
      Type:  defect  |      Status:  new                                           
  Priority:  normal  |   Milestone:  Untriaged                                     
 Component:  distro  |     Version:                                                
Resolution:          |    Keywords:  security-integration, security, rainbow, sugar
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by tomeu):

 Replying to [comment:3 marco]:
 >  * The user open a file from the datastore (or resume an activity)
 >
 >    1. Journal inform rainbow that an activity should have access to a
 datastore object.
 >    2. The activity is started and it's given an object id.
 >    3. The activity call the datastore service to checkout the file.
 >    4. Datastore check with rainbow if the activity can access the file.
 >    5. If the activity has the right permissions the datastore returns
 the metadata and give access to the file to the Activity.

 So, for Update1 we are going to have security in place and we want to hand
 the activity a read-only hard link to the file inside the Datastore.

 To enforce that this file is read only, Michael suggested this:


 {{{
 <tomeu> m_stone: when security is in place, how will the read-only be
 enforced?
 <m_stone> tomeu: directory & file permissions.
 <m_stone> here's one way it might work.
  you make a directory for the activity you want to have access.
  you make that directory 750 olpc/<gid> where <gid> is the activity's gid.
  inside the dir, you put your file and you make it 460 <uid>/olpc
  that way only the activity can read the file.
  or you make it 660 <uid>/olpc if you also want to allow writes.
 <m_stone> these permission-changes can be done either by a uid 0 daemon,
 by a
  setuid 0 shim, by sudo, or by consolehelper/userhelper.
 }}}

 I see three things we need in order to implement this in the DS:

  - A way to identify the caller (the dbus connection can hand us the
 caller bus_name?).
  - A way to get the uid and gid of the caller.
  - A way to do the permission changes.

 Is the Rainbow service going to provide all of that to us? Can we define
 the API?

-- 
Ticket URL: <http://dev.laptop.org/ticket/3801#comment:4>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system