| Top |  |  |  |  | 
| org.freedesktop.Flatpak.Developmentorg.freedesktop.Flatpak.Development — Flatpak development interface | 
HostCommand (IN ay cwd_path, IN aay argv, IN a{uh} fds, IN a{ss} envs, IN u flags, OUT u pid); HostCommandSignal (IN u pid, IN u signal, IN b to_process_group);
The Development interface 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: it is a sandbox escape allowing arbitrary code execution, and must not be allowed for applications where sandboxing is intended to be a security boundary.
However, it is very useful when using Flatpak for distribution and choice of runtime library stack, without intending to create a security boundary. For instance, if an IDE like GNOME Builder is distributed as a trusted Flatpak app and will be used to build other Flatpak apps, it needs to use this facility to launch a Flatpak build operation inside the sandbox, because otherwise recursive calls to flatpak will not work.
This interface is provided on the D-Bus session bus by the well-known D-Bus name org.freedesktop.Flatpak, at the object path /org/freedesktop/Flatpak/Development.
This documentation describes version 1 of this interface.
HostCommand (IN  ay    cwd_path,
             IN  aay   argv,
             IN  a{uh} fds,
             IN  a{ss} envs,
             IN  u     flags,
             OUT u     pid);
This method lets trusted applications (insider or outside a sandbox) run arbitrary commands in the user's session, outside any sandbox.
The following flags values are supported:
| 1 (FLATPAK_HOST_COMMAND_FLAGS_CLEAR_ENV) | Clear the environment. | 
| 2 (FLATPAK_HOST_COMMAND_FLAGS_WATCH_BUS) | Kill the sandbox when the caller disappears from the session bus. | 
Unknown (unsupported) flags are an error and will cause HostCommand() to fail.
Note that unlike Spawn(), there is no options parameter here.
| 
 | the working directory for the new process | 
| 
 | the argv for the new process, starting with the executable to launch | 
| 
 | an array of file descriptors to pass to the new process | 
| 
 | an array of variable/value pairs for the environment of the new process | 
| 
 | flags | 
| 
 | the PID of the new process | 
HostCommandSignal (IN  u pid,
                   IN  u signal,
                   IN  b to_process_group);
This method lets you send a Unix signal to a process
that was started with HostCommand().
The pid argument here must be a PID that was returned by a
call to HostCommand() from the same sender: terminating unrelated
processes is not allowed.
| 
 | the process ID on the host system | 
| 
 | the signal to send (see signal(7)) | 
| 
 | whether to send the signal to the process group | 
HostCommandExited (u pid,
                   u exit_status);
Emitted when a process started by
HostCommand() exits.
Use g_spawn_check_exit_status(), or the macros such as
WIFEXITED documented in
waitpid(2),
to interpret the exit_status.
This signal is not emitted for processes that were not launched directly by HostCommand(), for example if a process launched by HostCommand() runs foreground or background child processes.
| 
 | the PID of the process that has ended | 
| 
 | the wait status (see waitpid(2)) |