[sugar] Multiple documents

[Michael Stone]

Bert,

First, my apologies about the epic proportions of this email. In it, I
attempt to explain both my working perspective on the usages of the
terms 'activity', 'Activity', and 'Activity instance' and the
implications of our recent security work on the pratical meaning of
these terms.

If the wiki or Trac comes to feel like a more appropriate place for
these explanations and ruminations, then please feel free to move the
discussion to that venue.

Michael



Now, while I cannot speak for the Sugar team as a whole, in the
course of regular conversation, I find myself employing all of the
following notions: (cast in terms of a running example of painting) of
'activity', 'Activity' and 'Activity instance':

'Activity':
  a) the human action of painting, digital or not,

  b) the digital artifacts collectively named 'Paint' (software) and
  'a Painting' (data) that can be combined and 'activated' to allow a
  child to paint with a laptop,

  c) the design-level designation of the time intervals in which a
  child is painting by means of the 'Paint' software as the time in
  which the child is 'Painting' (on 'a Painting', no less),

  d) the digital states that occur on one or more communicating
  laptops during the largest connected interval of time containing
  some fixed time ('now') in which one or more children are Painting.

    [for Croquet folks: alternately, the versions defined under the
    possibility of the pseudo-temporal environment governing one
    session of Painting?]

Thus, in these terms, we might observe two children who are
synchronously or asynchronously collaborating in the activity of
painting by Painting together on a shared Painting by means of the
Activity named Paint, ultimately producing zero or more related
paintings.

'Activity instance': 
  (static sense): 'a specific Activity of sense (b)'
  (dynamic sense): A sited collection of objects, represented by one
      DBus object but in reality a heterogenous collection, with
      which a child interacts. Example: the DBus object, file system
      resources (see 'island', below), processes (i.e. kernel tasks),
      network resources, &etc. that together make up the whole of (a
      running Paint Activity and the Painting that it is
      manipulating). 

We might say: a specific Painting (static sense) will be manipulated
into a new Painting (static sense) during some specific instance of
the Activity of Painting. That specific 'program run' is an 'Activity
instance' in the dynamic sense.



... whew ...



Now for security considerations. First, a tad more terminology:

'Bitfrost': The high-level security design document to which we are
trying to conform.

'Rainbow' : Our implementation of the privileged security daemon
described in Bitfrost.

'VServer' : A virtualization technology that wraps the kernel's
syscall interface in order to gain fine-grained control over
kernel/userspace interactions.

'Security context': The unit of control provided by VServer. Contexts
contain one or more processes (tasks) and are identified by 'context
ids', confusing abbreviated as 'xids' (in contrast to X Windows'
'XIDS'). 

'To be secure' : 
  to prevent hardware damage, 
  to allow for safe updates to software on the system, 
  to protect privacy and to defend against impersonation, 
  to protect the integrity of the mesh, 
  and to prevent denial of service attacks

'Containerization': The process by which activity instances (dynamic
sense) can be isolated from one another and from the underlying
system.

'island': A directory into which we chroot() when creating a new
security context, before activating an Activity inside that context.

Now, to try to give the Security Team's perspective on the questions
below:

> The questions of how multiple activity instances are handled in Sugar  
> remains open. And even the way it is handled now is going to be  
> replaced "soon" with those security containers which from what I  
> heard yet appear to make it even harder to create efficient  
> solutions. In the earlier days of Sugar it appeared as if an activity  
> implementation would be allowed to manage its instances on its own.  
> Step by step this has been made harder. Now it appears to be required  
> that every instance is a separate process that starts and lives on  
> its own in its virtual container. Which is way inefficient, I  
> seriously hope I misunderstand intentions. But requests for detailed  
> plans have not been answered either.

In philosophy, our design goal is to encourage activity designers to use
dynamic Activity instances running in separate containers to the
extent that resource constraints allow because doing so enables us to
statically provide better protection against viral documents, against
data that crashes the activity instance, and against accidental
breaches of privacy caused by inadequately fine collaboration
granularity.

In practice, however, we won't prevent activities from employing a
factory scheme to better share resources at the expense of degrading
our ability to provide the protections described above and at the
additional conceivable expense of degrading the quality of the
accounting statistics we are able to provide to the various resource
consumption managers (e.g. disk quotas, OOM killer, etc)

In the long run, we hope to do an end run around the issue by
inventing a mechanism to share many resources across containers, by,
for example, regarding containers as prototype-objects that can be
descheduled (halting all processes inside the container), cloned
(installing a lazy copy-on-write resource sharing strategy), and then
rescheduled. Unfortunately, however, this is a research topic, not an
implementation strategy.

> Seriously...  how should activities save/serialize multiple files for
> correct indexing/viewing in the Journal?  We need an answer
> yesterday.

The interaction we want is basically one of:

'For user-owned files, the Activity instance asks Sugar to prompt the
user to select the file/package/whatever. The activity will be
notified over DBus when the chosen file (or directory?) is available.' 

  Design Note: It is *necessary* that Sugar do the prompting because
  it is a core component of our security model that Activity instances
  (dynamic sense) be prevented from ever seeing user documents
  (Activity instances in the static sense) that they have not been
  explicitly granted access to by the user. See ticket #2328 for
  details.

  Implementation Note: In practice, after the user has indicated the
  desired resources to Sugar, Sugar will inform Rainbow. Rainbow will
  then (under normal circumstances) proceed by bind-mounting the
  requested files and directories into the island containing the
  requesting activity instance.

  However, none of this has been written yet; the security team has
  been preoccupied building the machinery to construct the containers
  in which the activities may be started. 


'For files invisible to the user, e.g. cache files, bytecode files,
etc., the activity may request at installation time that it be
provided with a writable directory backed by persistent storage.'
  
  We discourage the use of this directory because, by using the
  datastore, we can provide transparent checkpointing. This
  checkpointing is valuable not only for user documents but also for
  configuration files because it reduces the risk posed by viral
  documents.

  We do not yet have a UI designed by which this data cache could be
  wiped by the user to return an activity to its installation state.

  (For that matter, we don't yet have a security-compatible technique
  for installing activities, but that is present work; see ticket
  #2009)


> If I understand the Sugar philosophy correctly, we won't have
> multiple documents per activity. If we want to have multiple
> documents opened at the same time, these would be multiple instances
> of the same activity.

Philosophically speaking, yes. In practice, however, its up to the
activity author and the datastore folks to negotiate what constitutes
a "document" (what I would call an 'Activity instance in the static
sense').

Practically speaking, do keep in mind the requirements that Bitfrost
imposes on how the datastore and the filesystem may be accessed by
Activity instances in the dynamic sense. 

> And if so, what would one activity instance have to to do to create
> a new instance?

Instruct sugar to create a new instance, by using the API provided in 

  sugar/activity/activityfactory.py