Is this related to the proposal to build a "desktop" via Project Atomic? That seems to me a much simpler approach. TBH, my "ideal desktop" would look like a ChromeBook except 1. Project Atomic as the OS, serving up web apps in containers, and 2. Firefox Developer Edition as the browser. On Wed, May 27, 2015 at 2:50 AM, Alexander Larsson <alexl@xxxxxxxxxx> 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 > some links to technical details at the end of the mail[1]. The basic > idea is that we have two sources (both ostree trees), one called the > runtime (/usr), and one called the app (/app), which get combined in a > container-like environment at launch time by xdg-app, with configurable > degrees of sandboxing. There is also some interaction with the host > system so that installed desktop files show up in the shell and dbus > session services from apps work. > > xdg-app has two major goals, the first is to allow applications to run > in a sandboxed environment with minimal access to the host. The second > is to allow third parties to create and distribute applications that > run on all distributions (and the sandboxing helps making this less > risky). To facilitate and test this I've also created an upstream > gnome runtime[2] that gnome applications can chose to use. I'm also > working on various Portal APIs[3] that allow sandboxed applications to > safely interact with the system. > > But, third party applications are a long way off in the future, and so > are sandboxed applications (which need not only a fleshed out set of > sandbox APIs, but also modifications to individual apps). In the > meantime it is still interesting to run bundled applications. For > instance in the context of an Atomic-based Fedora Workstation (with > readonly /usr), or if you want to run older or newer versions of > applications than your distribution is shipping. > > It would make a lot of sense to use the existing packages in Fedora > for this. And in order to kickstart discussions about this I've > created an initial sample of a possible Fedora runtime using > rpm-ostree and the Fedora 22 repositories: > > https://github.com/alexlarsson/fedora-runtime > > Building this produces a repo with the main runtime > (org.fedoraproject.Platform) and a sdk runtime (org.fedoraproject.Sdk) > which has some additional tools for app creation and debugging. It > also builds .Var subruntimes that contain /var with the rpm db > for use when building apps. The current package set is mostly based on > what is in the gnome one, so don't consider this official in any way. > > These runtimes are made to work with xdg-app 0.3.0 which are now in > updates-testing for F21 and F22. You also need rpm-ostree from git > master for the container support to build the fedra runtime. > > In order to test the runtime I've also created a firefox application > bundle. Unfortunately it requires some hacks in order to be relocated > to /app, and to work as a bundle. However, it works pretty well, > running somewhat contained with only access to the Downloads xdg > directory and with ~/.mozilla being redirected to the per-app > persistant data directory (~/.var/app/org.fedoraproject.firefox). Note > however, that I would not consider this properly sandboxed, as it uses > X11 for rendering, which is not very secure. > > The scripts to build the firefox bundle is here: > > https://github.com/alexlarsson/fedora-apps > > I've also put up a xdg-app repository so that you can easily test this: > (Run these commands as non-root, due to the --user args) > > xdg-app add-remote --user --no-gpg-verify fedora http://people.redhat.com/~alexl/repo > xdg-app install-runtime --user fedora org.fedoraproject.Platform 22 > xdg-app install-app --user fedora org.fedoraproject.firefox > xdg-app run org.fedoraproject.firefox > > Once installed the desktop file will be exported to the session, so > you should also be able to launch it from the shell. In theory this > should work on any distro, but I've only tried it on F21. > > The question is, would the Fedora project be interested in supplying > and maintaining a Fedora runtime like this, which allows us (and > others) to create applications using the fedora base. And if we do, > exactly what should be considered part of the basic platform. > > 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. > > An added complexity is that anything in the runtime that relies on > some kind of IPC to the host (say the pulseaudio client libraries, or > something that uses a dbus interface on the host) requires the host > side of that IPC to remain available and backwards compatible in > future versions of the distro, so we should err on exposing a minimal > set of IPC. > > There is also some changes that may be required in the distro to keep > unnecessary dependencies out of the runtime. For instance anything > related to hardware or system initialization is completely > unnecessary. Luckily much of this is being fixed by similar needs from > docker already. > > 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. > > There are also some custom configuration that a runtime needs. For > instance, the build script for the fedora runtime above drops in a new > fontconfig file that adds a /app/share/fonts fontdir for app-bundled > fonts and configuration to include the host fonts (which xdg-app > exposes in /run/host/fonts). This would be nicer if this was just a > fontconfig subpackage we could pull in, and I'm sure there are more > similar configuration options that would be needed. > > 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. > > 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. > > 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). > > There are clearly a lot of details here, but I'll stop here and throw > this out as the start of a discussion. I'll gladly reply to any > questions people may have. > > > [1] More information: > My devconf talk: https://www.youtube.com/watch?v=t-2a_XYJPEY > gnome wiki: https://wiki.gnome.org/Projects/SandboxedApps > xdg-app code: https://github.com/alexlarsson/xdg-app > > [2] Announcement of gnome runtime: > https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-are-out/ > > [3] https://wiki.gnome.org/Projects/SandboxedApps/DocumentPortal > https://wiki.gnome.org/Projects/SandboxedApps/Sandbox > > [4] > https://mail.gnome.org/archives/gnome-os-list/2015-February/msg00009.html > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl@xxxxxxxxxx alexander.larsson@xxxxxxxxx > He's a war-weary Republican vampire hunter on a search for his missing > sister. She's a ditzy winged queen of the dead with the power to see > death. They fight crime! > > -- > desktop mailing list > desktop@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/desktop -- OSJourno: Robust Power Tools for Digital Journalists http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
