[sugar] Initial Security Patches

[Michael Stone]

Apologies for the self-reply, but I realized that I failed to answer
Marco's penultimate question.

> Marco:
> So we either just launch the activity executable from Sugar (which is
> what I assume bitfrost is doing) or we make bitfrost run even without
> vserver.

Implementing Bitfrost is presently incompatible with activity launching
happening inside sugar because manipulating containers is a privileged
operation that has hard dependencies on VServer (much to the chagrin of
the kernel folks) or something much like it.

Thus, for Trial 3, we're aiming to implement two profiles: "on" and
"off". In the "on" state, we make active as much of Bitfrost as is
currently implemented. In the "off" state, we provide compatibility with
existing Sugar activities, but make essentially no activity-visible
changes in API or available resources.

This plan derives primarily from our need to preserve the ability to
develop activities under jhbuild on non-Linux systems while facing the
reality of our dwindling implementation resources. In other words, while
ideally Bitfrost would run on non-OLPC images and on non-Linux systems,
our portability and external compatibility are hog-tied by our
dependence on so many privileged or Linux-only resources like:

  a) bind-mounts and VServer, both of which are are linux-only

  b) super-user access to call chroot(), to make bind-mounts, and to
     manipulate VServer

  c) ability to sit on the system bus.

These dependencies of the "real" implmentation make the goal of some
"mock" implementation seem difficult and not worth the resources it
would take to see through.

I write this just to inform the sugar-list of what we have been working
toward so far, not to write what has been set in stone. If you think we
need to have different aims for Trial-3, by all means speak while there
is time for us to change direction, (though understand that we are fairly
committed to the present plan).

Michael