joyride 2128 smoketest

[Erik Garrison]

On Thu, Jul 10, 2008 at 10:53:20AM -0400, Michael Stone wrote:
> > We already ship one on the laptop (yum)!  Perhaps we could be using it
> > to handle our activity updates?  If the problem is that yum is slow and
> > awful, then maybe we need to start thinking about using apt.
> 
> 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.

> 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?

>   * 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.

>   * 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.

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.

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.

How are we planning on providing security updates?  Do you agree that a
package manager-based solution is tenable?

-Erik