[sugar] Activity Launching Change Proposal

[Michael Stone]

Dear Sugar Developers,

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