mirror of https://github.com/cutefishos/appmotor
You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
When booster is executing in sandbox as an applicatiom booster, it needs to verify that command line received from invoker matches Exec line in application desktop file, application launch is allowed, and permissions granted are as was expected at the time of booster launch. Provide booster-generic@.service that can be used for instantiating sandboxed application boosters. D-Bus ipc with sailjaild is modified version of similar code in sailjailclient. The biggest difference is that this version uses private connection via libdbus to avoid leaving stray dbus connections or threads behind when transferring control to application code without use of exec*() functions. Remove cap_sys_ptrace from booster executable as makes it impossible to run the booster within a no-new-privs sandbox. Fix socket passing from booster instance to booster daemon so that it works also when invoker is running in different namespace than booster instance (invoker pid might be unresolvable). Replace ad-hoc booster argument parsing with getopt_long(). Fix issues with argv handling: using const pointers for non-const data, passing data by reference between objects that might have different lifespans and never releasing the dynamically allocated arrays. Fix issues with env passing: duplicating invoker env at booster side as-is can lead to problems like loss of customg session bus socket address that has been set up by firejail. If booster bumps into command read problems, bailout immediately instead of relying on out-of sequence data possibly triggering exit due to unknown commands. As an enabler for sharing code between invoker (written in c) and daemon (written in c++), modify Logger class used by c++ code so that it is just a wrapper for logging functionality used by invoker. Signed-off-by: Simo Piiroinen <simo.piiroinen@jolla.com> |
4 years ago | |
|---|---|---|
| doc | 12 years ago | |
| rpm | 4 years ago | |
| scripts | 7 years ago | |
| src | 4 years ago | |
| .gitignore | 13 years ago | |
| CMakeLists.txt | 5 years ago | |
| COPYING.LESSER | 16 years ago | |
| README | 4 years ago | |
README
What is applauncherd?
==============================
Applauncherd is a daemon that helps to launch applications faster by
preloading dynamically linked libraries and caching stuff.
It also saves memory, because all launched applications share certain resources.
Applauncherd also provides support for fast single instance launches.
Some technical details are explained below.
Install applauncherd-doc for the Doxygen-based user documentation.
See INSTALL on how to build applauncherd and the documentation.
Building
==============================
BUILD_TESTS=1 ./configure
make
make doc
make install
Technical overview
==============================
Booster daemons (written using the provided library) are started as part of the
user session. The booster is responsible for forking the will-be-application
before knowing which application is going to be launched next. There can be
different kinds of boosters optimized for different kinds of
applications, e.g. Qt or QML.
In the current architecture boosters are implemented as seperate processes,
using the provided support library. Each booster process waits for launch
commands.
The user uses the launcher always through a special invoker program. The
invoker (/usr/bin/invoker) tells booster process to load an application
binary via a socket connection.
The application to be launched via applauncherd should be compiled as a
shared library or a position independent executable (-pie) and it should
always export main(). There's also a "booster" for all applications.
In that case exec() is used.
Technical details
==============================
Loading the binary is done with dlopen(), and therefore the
application needs to be compiled and linked as a shared library or a
position independent executable. The booster process also sets the
environment variables. Finally, it finds the main function in the
application binary with dlsym() and calls the main() with the command
line arguments given by the invoker.
Booster processes do some initializations that cannot be shared among
other processes and therefore have to be done after forking. This allows,
for instance, instantiating a application before knowing the
name of the application. Then the booster process waits for a connection
from the invoker with the information about which application should be
launched.
Contributors
==============================
People who have contributed to mapplauncherd:
Robin Burchell
John Brooks
Thomas Perl
People who have contributed to meegotouch-applauncherd:
Olli Leppänen
Jussi Lind
Juha Lintula
Pertti Kellomäki
Antti Kervinen
Nimika Keshri
Alexey Shilov
Oskari Timperi
Some parts of the code is based on the maemo-launcher by:
Guillem Jover
Michael Natterer