Files
flatpak/tests/libpreload.c
Simon McVittie d19f6c330a tests: Assert that --env= does not go in flatpak run or bwrap environ
For the portal's use of --env-fd= to be safe, we want the environment
variables that it sets to end up in the environment for the program
that is run by `bwrap` as process 2, but they must not go into the
environment that gets used to run `flatpak run` or `bwrap`. Assert
that this is the case.

For completeness, we're testing both --env= and --env-fd= here,
even though the earlier commit
"portal: Do not use caller-supplied variables in environment"
always uses --env-fd=.

Part-of: https://github.com/flatpak/flatpak/security/advisories/GHSA-4ppf-fxf6-vxg2
Signed-off-by: Simon McVittie <smcv@collabora.com>
2021-01-14 09:33:24 +01:00

32 lines
740 B
C

/*
* Copyright 2021 Collabora Ltd.
* SPDX-License-Identifier: LGPL-2-or-later
*/
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
__attribute__((constructor)) static void
ctor (void)
{
pid_t me = getpid ();
struct stat buf;
fprintf (stderr, "LD_PRELOAD module got loaded by process %d\n", me);
if (stat ("/.flatpak-info", &buf) == 0)
{
fprintf (stderr, "OK: pid %d is in a Flatpak sandbox\n", me);
}
else
{
/* If the --env=LD_PRELOAD had come from a call to flatpak-portal,
* then this would be a sandbox escape (GHSA-4ppf-fxf6-vxg2). */
fprintf (stderr, "Error: pid %d is not in a Flatpak sandbox\n", me);
abort ();
}
}