Fedora runtimes and sandboxed desktop applications

[Matthew Miller]

On Wed, May 27, 2015 at 11:50:15AM +0200, Alexander Larsson wrote:
> I'm working on an application sandboxing system called xdg-app, and
> the surrounding echo-system. I won't go into details, but there are

Very interesting stuff! I know you've been working on this for a
while and I'm glad to see it's gotten to the point where it's useful
to bring here. :)

I probably have _more_ comments later, but a few random initial ones:


> Defining a platform requires a lot of care. It is a balance between
> wanting as much as possible in it to share more maintainance and
> updates and make it easier to write apps and on the other hand trying
> to keep the basic platfrom small, maintained and of high quality. The
> ABI requirements for a platform is a bit different than a regular
> distro. The goal is to allow apps built against a particular platform
> to run for years to come, so it should only do security and very
> important bugfix updates, and *never* break ABI. On the other hand,
> its easy to break ABI in a later version of the runtime, because they
> are parallel installed. This is somewhat different than our current
> updates which revs libraries during the distro lifetime as long as it
> also updates all users of it.

This is definitely something I know that _users_ are interested in. The
"*never*" part is hard, though, because it requires a commitment for
the backporting of security patches, and although over the last year
the Fedora Security Team has stepped up activity, we'd really wantto
make sure we have the resources required to keep our promises
long-term.


> One thing that is different from docker however, is that we generally
> want translations/locales in the runtime. But these are pretty large,
> so we want to handle them in a smart way. xdg-app has a feature that
> allows splitting a runtime into a base and a set of optional
> extensions that are mounted in the sandbox only when they are
> installed. I use this in the gnome runtime to split out each
> locale. Unfortunately Fedora uses a single large locale-archive file
> for its locales, so its hard to do that. This needs some research to
> figure out how to do properly.

Yeah, because as you say translations inside Docker have been lower
priority, most of the effort so far has been on just ditching them
rather than the modularization this needs.


> Creating applications from fedora packages is a bit more
> complicated. The primary reason is that they need to be relocated to
> /app. In the hacky script above I just extract the rpm contents to
> /app and then rewrite some rpaths and shell scripts. A less hacky
> approach is to rebuild the rpms with a different rpm %_prefix macro,
> or to use relocatable rpms. It is not really significantly different
> from creating rpms to use in software collections though, so we have
> some experience with this.

Let's figure out what's needed and get that into base RPM. I have been
pretty clearly told by RH management that there's support for that as
long as we have clear requirements and a sensible plan. I think one of
the lessons learned from Software Collections is that the macro system
used there turned out to be harder than it looks. 


> Packaging an application also requires some changes other than the
> relocatability itself. First of all, all "exported" files from an
> application (such as icons, desktop files, dbus service files, or
> other files that are read from outside the app itself) must have the
> application id (which is a dbus/java-style reverse dns name) as a
> filename prefix. This is both for avoiding conflicts, and for security
> reasons, see [4]. However, it wouldn't necessarily be a problem if we
> just did such changes on the regular fedora packages too, as a regular
> fedora packaging policy.

Possibly this could be done automatically with the "/app-relocated"
builds? I don't know offhand how popular / useful this would be as
global policy.

> One issue is that as third party packagers of applications we should
> not use the "official" app ids for our builds, as they would conflict
> with upstream doing their own release. So, our package of
> org.gnome.gedit should probably be called org.fedoraproject.gedit,
> which may require some minor tweaks to the build (for instance, this
> affects the dbus name the app uses for dbus activated desktop files,
> as well as the name of the desktop file itself).

I guess that makes sense as our package namespace is already flat.
Maybe something like org.fedoraproject.pkg.gedit, to give room to do
something different in the future? Ehhh, bikeshedding. :)

-- 
Matthew Miller
<mattdm at fedoraproject.org>
Fedora Project Leader