Just because stdout/stderr happen to be going to a terminal doesn't
necessarily mean that we want the command launched by HostCommand
to take ownership of the terminal - in the case where 'flatpak run'
is launched from a terminal, stderr will typically be left pointing
to the terminal for any command. In that case the terminal already
has a controlling process, and TIOCSCTTY will fail; avoid scary
messages by making the failure only a g_debug()
This was using the "from" fd from the fd_map, which will have already been
closed by time we reach this portion of the child setup.
Tracking the movement of FDs while resolving the remappings is rather
tedious and error prone, so just locate the final fd before calling
the ioctl() in child setup.
This is needed by e.g gnome-builder that want to pass this pid to
a profiler service. Its not really less secure/sandboxed this way,
because the app can launch whatever he wants in the host, which could
anyway talk back and report the real pid.
This lets any client, possibly in a sandbox if it has access to the
session helper, spawn a process on the host, outside any sandbox.
Clearly this is not something you typically want a sandboxed app to
do. However, it is sometimes very useful when using flatpak mainly
for distribution. For instance, an IDE needs to use this to launch a
flatpak build operation inside the sandbox. (Because otherwise recursive
calls to flatpak will not work.)
Using the bus name as the name of the service file is mandatory
for system services, and recommended for session services.
Signed-off-by: Simon McVittie <smcv@debian.org>
This moves a all source code into separate subdirs per binary. The
helper and the generic stuff goes into lib/ which is then used by all
the others. For now this is a completely internal library, but at
some point we will probably clean it up and expose some subset.
Also, we move the dbus proxy to libexecdir.