libostree attempts to strip the setuid and setgid bits from file
permissions in user-mode checkouts, which, if successful, would make
Flatpak's check for setuid ineffective and unnecessary. In versions
older than 2017.7 this was not consistently applied, making commits
2c8e241 and 02a299f necessary to defeat CVE-2017-9780 (see #845).
libostree 2017.7 removes setuid and setgid bits more thoroughly
as a result of fixing https://github.com/ostreedev/ostree/issues/633
in PR https://github.com/ostreedev/ostree/pull/903, which means that
this test fails when linking flatpak 0.8.x to libostree 2017.7.
Signed-off-by: Simon McVittie <smcv@debian.org>
This is solved in a much nicer way on master, using new ostree
APIs. However, here we take a brute-force approach of scanning
all staged files and ensuring we don't have any files or
directories with invalid modes before committing the transaction.
If any bad permissions were found we delete the entire staging
directory.
If you run "flatpak update" then we will never update to
a commit that is older than the currently installed one. This
protects against a man-in-the-middle attack that would otherwise
let the attacker downgrade to a previously signed version that
may have some vulnerability.
(cherry picked from commit 3ff6d312de)
This makes the ostree trivial-httpd --autoexit feature work better,
because it seems to exit whenever the root directory changes (i.e. not
only when its deleted).
This means the root dir can't be the repo (because then we can't
update the repo), or the base testdir (because we create files there
too), so instead we make the repo $testdir/repos/test and
$testdir/repos as the httpd root.
If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
Use FLATPAK_TESTS_VALGRIND_LEAKS to check for leaks.
We're not currently passing the leak checks, so this helps letting
us make valgrind checks useful.
This means we don't have to add it to EXTRA_DIST, and also means
we can have generated (non-distributed) test data in future if we
want to.
Signed-off-by: Simon McVittie <smcv@debian.org>
In autobuilder environments that deprive the build of capabilities,
it is entirely possible that we have a system bwrap(1) but cannot
run it, for example because CAP_SYS_ADMIN has been excluded from
the capability bounding set. Tell the tests which bwrap we are
going to run, so we can run it in a simpler way and see whether
it works.
Debian's sbuild autobuilder currently suffers from a different
issue in which pivot_root(2) returns EINVAL, possibly caused by
sbuild being chroot-based and so not having the mount point
structure that is required for pivot_root. This avoids the
problematic build-time tests there too; they work on ci.debian.net,
which uses lxc instead of chroots, and in virtual machines.
Because $(BWRAP) might be non-absolute, we need to search PATH for it.
Signed-off-by: Simon McVittie <smcv@debian.org>
An assertion failure that says res is FALSE is a lot less useful
than an assertion failure that says we got a specific GError.
Signed-off-by: Simon McVittie <smcv@debian.org>
This catches regressions in the fix in the previous commit, where old
stale .py[oc] files can wrongly become "unstale" when we change the
.py file mtime to 1.
dbus-launch is X11-specific and contains a lot of legacy code to
support X11 autolaunching. It should not be part of the Wayland
(and/or Mir) future.
Start a dbus-daemon directly instead.
One of the variations tested on Debian's reproducible build
infrastructure is that the second build is done in a French locale.
This test fails there, because it doesn't see "Usage:" in the help.
Signed-off-by: Simon McVittie <smcv@debian.org>
This lets distributors share a system copy of bubblewrap (>= 0.1.0)
between Flatpak and any other projects that benefit from it, if they are
careful to keep new versions in sync. The default is still to use the
bundled submodule, ensuring compatibility and simplifying dependencies.
Enable $PATH search everywhere that runs bwrap, so that $BWRAP doesn't
necessarily need to be a fully-qualified path.
Signed-off-by: Simon McVittie <smcv@debian.org>
