[sugar] Activity Launching Change Proposal

[Dan Williams]

On Fri, 2007-06-22 at 12:43 -0400, Michael Stone wrote:
> Dear Sugar Developers,

Note that we need to keep sugar-jhbuild working too, so any sugar
changes and/or rainbow code will need to gracefully deal with lack of
vserver and just launch the activity without containers if vserver's not
around.  I'm not about to run vserver on my regular laptop, nor will
most other people since they can't get vserver kernels for their distro
(let alone people running sugar on OS X :)

Dan

> Noah Kantrowitz (coderanger) and myself (Michael Stone, ashsong) are
> presently implementing the Bitfrost security spec. Since one of the core
> ideas of Bitfrost is to isolate activities from one another and from
> critical parts of the system using the Linux-VServer virtualization
> technology, we're presently changing Sugar to allow activities to be
> started in controlled VServer environments called "containers".
> 
> Unfortunately, it is difficult to start activities in containers using
> the present model of DBus service activation. We would therefore like to
> revise the mechanism used to start activities and are seeking input on
> how best to do this. 
> 
> As background, I will first describe how activities are presently launched.
> Then, I will explain the incompatibility between the present DBus-activation
> based model and a world with containers. Finally, I will describe our proposed
> solution.
> 
> Present Situation:
> 
>   "Activities" are presently launched as follows:
> 
>   1. Clicking on an activity launch icon in Sugar triggers the
>      `sugar.shell.view.frame.ActivitiesBox._activity_clicked_cb' callback which
>      in turn fires off a call to `sugar.shell.view.start_activity(...)'
>   2. `sugar.Shell.start_activity' calls
>      `sugar.activity.activityfactory.create()' which constructs a
>      `sugar.activity.activityfactory.ActivityCreationHandler', initialized with
>      an `ActivityHandle' describing the activity being started.
>   3. The `__init__' method of ActivityCreationHandler connects to the DBus
>      session bus, uses a well-known name to locate an appropriate
>      ActivityFactory _DBus object_, and calls this _DBus object's_ `create'
>      method.
>      (The ActivityCreationHandler also installs callbacks to log the success or
>      failure of the attempt to launch the activity)
>   4. The appropriate `ActivityServiceFactory' DBus service is automatically
>      launched by DBus from a service file if necessary. Then its `create' method
>      is dispatched, which results in the activity itself being constructed and
>      presented.
> 
> Problem:
> 
>   The basic incompatibility between the present activation-based model and
>   containerization lies in step (4) above; namely, that creating and
>   manipulating containers is a privileged operation which the DBus session
>   daemon is neither permitted, nor designed to effect and is one which demands
>   detailed knowledge of the Bitfrost security model to operate correctly.
> 
>   The solution proposed by the Bitfrost spec is to encapsulate (to the extent
>   possible) the implementation of Bitfrost in a privileged security daemon
>   which we are calling "Rainbow".  Rainbow is designed to, among other things,
>   start activities in appropriately restricted containers. Ideally, we would
>   just replace step (3) with something like:
> 
>     3b. The `__init__' method of ActivityCreationHandler connects to the DBus
>     system bus, locates the `org.laptop.security.Rainbow' service, and calls
>     the `create_activity' method of Rainbow's `org.laptop.security.Rainbow'
>     interface. 
> 
>   where Rainbow's `create_activity' method would handle all the details.
>   
>   Unfortunately, in attempting to implement this `create_activity' method, we
>   discovered that it is very inconvenient to start activities through DBus
>   *inside containers*.
> 
>   The low-level problem is that, after a Rainbow-child-process enters a
>   container to start the desired activity, the Rainbow-child-process must
>   actually start the activity's 'ActivityFactory', then send it a 'create'
>   message *over the session bus*
> 
> Solution:
> 
>   The procedure described in the preceding paragraph for actually starting
>   activities inside an active container is overly-complicated at best and is
>   highly error-prone at worst. A much simpler, more robust procedure would be
>   leave out the DBus call to the factory's 'create' method and would merely
>   rely on the execution of the factory process itself to perform whatever
>   activity is appropriate to make a new activity instance inside the container.
>   
> Feedback on this proposal in general and on the appropriate information to pass
> to the proposed factory executable would be most appreciated.
> 
> Thanks,
> 
> Michael and Noah
> 
>  
> 
> 
> 
> 
> 
>   
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar