3 Commits (402d9fde2f666f1628bbac3ed91518cc41fcd6b0)

Author SHA1 Message Date
Simo Piiroinen 833b551af1 [mapplauncerd] Sandboxed application boosters. JB#53844 OMP#JOLLA-43
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
Simo Piiroinen 1a3ec406de [mapplauncherd] Avoid using signals for peer termination. Fixes JB#53845 OMP#JOLLA-44
Invoker and booster instance make up a process pair that are meant to exit
at the same time. To arrange this a) when invoker is about to exit, it sends
a terminating signal to booster instance, and b) when booster instance
exits, booster daemon sends a terminating signal to invoker. Overall this
has worked well enough - save some hiccups from potential race conditions -
but it is not compatible with setup where invoker and booster daemon are
running in different namespaces and sending signals is not possible.

There is already an unix domain socket that is kept open for the lifetime of
boosted application - used for transferring application information from
invoker to booster daemon during startup and exit status from booster daemon
to invoker at exit time. This socket can be utilized also for detecting when
peer process exits.

Normally when application (booster instance) exits, booster daemon receives
SIGCHLD, collects application exit reason, forwards it to invoker via
booster socket, and invoker then makes exit with the same exit status as
what application used.

Augment this by having booster daemon watch over booster sockets and
terminate booster instance upon eof on socket. This accomplishes that
application gets killed if/when invoker dies.

Additionally all booster instances are terminated if booster daemon exits
due to SIGTERM.

In general, instead of simply closing booster socket at each end at exit
time, an orderly disconnect is done via: shutdown write end of the socket,
read data until eof is received, then close socket. If this is accomplished
successfully within reasonable time limit, there is no need to send signals
- both peers know that the other end is going to make an appropriate exit.

Previously booster daemon and invoker made an attempt to reproduce
application getting killed by some signal such as as SIGSEGV also at the
invoker side. As this produces false positive crash reports and complicates
things (some of the signals are terminal and can't be handled in
asynchronous manner) this is no longer done - only standard TERM and KILL
signals are used for terminating peers and even then it is done as a last
resort.

Invoker signal handler used non async signal safe functions, those
have been removed.

To ease ad-hoc debugging, logging is automatically switched from syslog to
stderr when booster/invoker is executed from interactive command line.

Signed-off-by: Simo Piiroinen <simo.piiroinen@jolla.com>
5 years ago
Juha Lintula ee9fe47996 Changes: single-instance library writes log messages to syslog instead of stderr
RevBy: Alexey Shilov, Dmitry Rozenshtein
14 years ago