joyride 2128 smoketest

[Michael Stone]

On Thu, Jul 10, 2008 at 02:35:23PM -0400, Erik Garrison wrote:
> On Thu, Jul 10, 2008 at 10:53:20AM -0400, Michael Stone wrote:
> > Here are several problems you might think about:
> > 
> > 1) We'd like people to be able to package activities on a wide variety
> > of systems including on Windows. To the best of my knowledge, it
> > currently requires nontrivial Unix expertise to produce most Unix
> > packaging formats.
> 
> I suggest we assist in .xo -> .rpm / .deb and obtain the benefits of a
> package manager on whatever fraction of the XOs run linux.  If we retain
> .xo files and an installer for Windows, then we are doing as well as we
> can be expected to on Windows.  At present are we even sure that
> Activities are going to run on Windows?  Activity maintainers will have
> to port them.

You misunderstand. A design goal of the .xo[l] format is for casual
developers whose primary platform is not Unix to be able to contribute
content to the XO. While there are certainly work-arounds that could be
built, for example a web-based builder or a really portable packaging
tool, it's presently challenging to build packages in the common formats
absent far more Unix know-how than is necessary to write activities.

> > 2) We'd like people to be able to install activities with relatively low
> > privilege -- in particular, without root privilege. Linux packaging
> > formats and guidelines often assume that the person installing packages
> > has access to root authority (or is able to do something comparable like
> > chroot + fakeroot). What can we do about this? For example:
> 
> By default XO users have access to root privelages (Terminal + su).  Why
> is it not acceptable for them to have access in the context of activity
> installation and upgrade?

XO users in some of our large deployments do not have access to root
privileges at all (save via developer key or privilege escalation attack).

> >   * RPM supports relocation and (for some packages) installation as an
> >     unprivileged user. However, privilege is needed in order to update
> >     the system rpm database. Perhaps we could teach RPM how to maintain
> >     two databases; one privileged and one not?
> 
> The typical use case for such an arrangement is a multi-user system in
> which users would like to install custom software without disturbing the
> system at large.  In the case of the XO there are no other users.  The
> actions of the principal user affect only that user.

You're not considering changes that country deployment teams make to the
XO which they expect will not be modified by end users of the XO (who do
not take active steps to control their system, e.g. by requesting a
developer key).

> >   * Alternately, we could imagine running activities in a copy-on-write
> >     (CoW) filesystem (union-mounted, FUSE, vserver, ...) with either a
> >     false sense of privilege (fakeroot) or a restricted form of real
> >     privilege (vserver, selinux, ...). Then we could install packages
> >     for activities which need them with relatively little hassle. 
> >          
> >       - How could we share disk usage costs between such activities?
> > 
> >       - Could we ever update the packages inside these containers?
> 
> This would be very messy.

Maybe yes, maybe no. It works quite well for building software (e.g.
pbuilder and mock) and for hosting servers (vserver).

> I conclude from your comments that our current security model
> discourages the use of existing package-based Linux software
> distribution systems.  I find it interesting that these same systems are
> crucial components in generic 'soft' Linux security models.

How familiar are you with Bitfrost?

> I suggest that, if we can adjust our security model to accept it, a
> package system could be used for both software installation and updates
> and the resolution of security concerns via security-oriented updates.

Which aspect of our security model would you suggest altering?

> How are we planning on providing security updates?  

When connectivity is available, via olpc-update (which is quite
bandwidth-efficient) and via our regular software releases to country
deployments otherwise.

> Do you agree that a package manager-based solution is tenable?

I believe that an acceptable package management system could be built
but I'm not aware of one that presently exists which satisfies our other
requirements.

Michael