PRoot allows running applications in a fake root fs without root permissions making it ideal to build portable bundles.
appimage-builder now supports building AppImages using this approach. In this post, you will find how
it works and how to use it.
Portable bundles and the resources resolution issue
To build an AppImage is required to pack the target application with all of its runtime dependencies and resources. Then comes the interesting part, configuring each piece of software to use the bundled resources and collaborate with the others. In short, all the bundled binaries must be relocatable.
Making relocatable binaries is not a trivial task if the source code is not accessible. Even if the source code is available the components that aren’t relocatable must be modified and rebuilt along with the app which implies a lot of effort that is not related to the app purpose.
A major part of the system components can be configured. Environment variables, configuration files, and other techniques are used for this purpose but there is no a standard way of telling every piece of software where to locate its dependencies and resources.
chroot to the rescue
The Linux kernel allows changing the root filesystem for a given group (process). This can be used to solve the
above-mentioned issue but there is a problem:
chroot requires superuser privileges. Luckily for us, there are ways of
Ptrace is a system call that allows us to control, intercept and manipulate
other systems calls. This can be used to rewrite every file related operation making it seems like they are being opened
in the root files system. By example:
/lib/x86_64-linux-gnu/libc-2.27.so can be translated to
/tmp/.mount-032940234/lib/x86_64-linux-gnu/libc-2.27.so. So if the files are deployed in the AppDir in the same
places that they are expected to be deployed in the system everything should work as expected. There is no need to patch
elf files, writing N+1 configuration files or patching source code.
PRoot does exactly what is mentioned above and a bit more. It allows binding parts of the real rootfs into the fake one making the system resources available into the app environment. This makes is a good candidate to be used while creating an AppImage bundle.
PRoot support on appimage-builder
Creating AppImages using this approach is quite simple now in
appimage-builder. To enable it, set
proot and include the proot binaries in the bundle. The following
snippet illustrates how to do it:
AppDir: apt: # your whole apt configuration goes here include: - proot runtime: generator: proot
In the back appimage-builder generates an AppRun file which calls proot by means of the embed ld.so ensuring it doesn’t load any binary from the base system and effectively launching the app inside a fake root environment with the following paths bound from the real file system:
As this is a quite new (at least to me) and promising way of creating AppImage bundles it’s not quite tested yet and
depends on the
proot ability to really intercept every file related syscall. Therefore it issues may raise in certain
environment in such cases please drop by our Github rerpo and
fill an issue so we can take a look at it and provide a solution.
Positive feedback in the form of github stars, word spreading or pull request is highly appreciated. Thanks for reading.