Fedora runtimes and sandboxed desktop applications

[Alexander Larsson]

On ons, 2015-05-27 at 08:56 -0400, Matthew Miller wrote:
> On Wed, May 27, 2015 at 11:50:15AM +0200, Alexander Larsson wrote:
> > 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. 
> 
> 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 want to
> make sure we have the resources required to keep our promises
> long-term.

I realize that "never break ABI" sounds scary, but that is what is what
is needed to keep old apps running. However, that doesn't necessarily
mean that we need to maintain it forever and ever. Its still possible to
run old unmaintained versions of fedora (although we don't recommend
it). In a similar fashion one could keep an old runtime around for an
old app you need to run (not so bad here as it affects only that app).
Furthermore, the set of packages where we need to give this guarantee is
not the whole distro, but a subset, and in particular a subset which
contains zero code that runs with elevated privileges (setuid et al
doesn't even work in a xdg-app sandbox).

That said, "stable ABI" is always a grey area. Does fixing an obvious
bug break ABI if code relies on the bug? In reality what happens is we
do our best to not break any real existing app, and if we accidentally
do we fix it in another update. This is trickier in a runtime as we may
not necessarily control or be able to test all the users of the runtime,
like we do in the fedora repos. In practice, "never change" probably
means "be more cautious about updates in a runtime than in a regular
distro update".

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

Are there any docs somewhere on how the locale-archive thing works? It
seems not a lot of distros are using that.

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

I think its just hard to automatically make some existing code
relocatable. Some code somewhere could just take the PREFIX define and
shove it deep into some static structure. xdg-app conceptually makes
things easier, because "/app" is always the same and the same length as
"/usr", but its still not something you can automatically replace.

The easiest way to relocate is to rebuild with a different prefix, but
even that may not work, as many of our packages are not designed to
support a non-/usr prefix. Take the firefox shell wrapper for instance.
It has hardcoded:
   MOZ_LIB_DIR="/usr/lib64"
   SECONDARY_LIB_DIR="/usr/lib"

It would be a small matter of programming to rewrite this at rpm build
time, but it is work that has to be done. Rewriting at install time is
harder, especially for strings that are in compiled code.

Then you have things like rpaths, module include paths for different
dynamic languages, etc... Its tricky. Maybe the people working on
Software Collections can weight in with their experience.

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

Some things can be done automatically. For instance its easy to rename
the desktop files, the icons and the dbus service files. However, it is
a bit trickier to make the app listen to a different dbus name. We're
working on a glib patch to make this easier:
  https://bugzilla.gnome.org/show_bug.cgi?id=743933
But in some cases you may have to change the code slightly.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a fiendish ninja dog-catcher looking for 'the Big One.' She's a 
wealthy out-of-work safe cracker who don't take no shit from nobody. They 
fight crime!