[Sugar-devel] [SLOBS] Long-term support for Sugar

[Peter Robinson]

On Mon, Sep 21, 2009 at 11:14 PM, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Mon, 21-09-2009 a las 17:28 -0400, Chris Ball escribió:
>> But then every child in Uruguay (plus other deployments that withhold
>> root from their users) would hate you 'cause they wouldn't be able to
>> install activities anymore.  A solution that results in a significant
>> percentage of Sugar's users not being able to download activities
>> anymore is not a solution.
>
> Trying to prevent users from gaining superuser privileges seems to be a
> misguided technical solution based on ignorance of the UNIX security
> model.
>
> However, a solution based on PackageKit would not require root
> privileges to control installation of software.  A simplified UI could
> be designed to display only Sugar Activities rather than revealing the
> full complexity of the system.
>
> Sure, it would still provide an ideal path to let a clever user escalate
> to root, but we just need to keep it quiet and those who decided to
> withhold root access from users would probably never realize that ;-)

I agree. I personally believe that if someone wants to get access to
root there's going to be any number of ways they can do so. After all
the default deployment comes with root access by default but I'm not
sure this is the case with a complete deployment. Afterall I thought
the whole idea was for the kids to be able to get under the hood!

>> If we could switch to .rpm *and* find a good way to install .rpms
>> without being root, though, that would be pretty compelling.
>
> Besides PackageKit, there are many ways we could bend rpm into doing
> what we need.

There's lots of ways to do it. I believe PackageKit has the following
advantages rather than having to "bend rpm":
- distribution and package format independent which means we can
engineer once in sugar and have it supported everywhere.
- I'm pretty sure it has good python bindings, again simplifying engineering
- works across multiple architectures and can deal with them (will be
very important with XO-2 going arm based).
- mass downstream distribution support

Is it a perfect fit? No. But at this point in time I think its the
best option that we have and without engineering resources coming out
our ears with the time to engineer the perfect solution I think it
fits pretty well. I'm also pretty sure some of the PK upstream
developers have offered to help out on fedora-olpc before.

> A 100% non-invasive solution, would consist in writing a suid wrapper
> that would check the output of "rpm -qpl WonderfulActivity-42.rpm" for
> files outside the designated Activity installation path and then run
> "rpm -i --noscripts WonderfulActivity-42.rpm" to install it.
>
> Another possibility would be playing with --root to create a separate
> rpm database, and run rpm with user privileges.  There are a bunch of
> other options that may help: --prefix, --reloc and --dbpath.
>
> Finally, by resorting to invasive -- but probably upstreamable --
> changes to the rpm code, we could make it check dependencies against the
> system database and perform an unprivileged installation in the user's
> home and recording the package in a user database.
>
> Sounds a bit complicated?  Well, think how much code and complexity it
> would let us drop from the Sugar codebase that we currently have to
> maintain.  Not to mention how much work it would take to improve it to
> the point of actual maturity.

Or you could write a script that extracts the rpm using cpio to the
users directory, use the relocate feature of rpm which is little used
and likely full of bugs but all of the above options leave us with two
problems:
- Hacks that generally won't be supported by upstream rpm getting us
into the situation we've been in the past with massively forked code
that causes other issues
- A solution that is only relevant for distributions that use rpm and
hence it then needs further engineering resources for other distros.

Peter