This is a convenient function which can be used with flags, adding option to return
real path of the file we are trying to open in case the sandboxed app has access
to it. It also registers this file automatically to document store so there is no
need to call grant_permission() afterwards.
Closes: #1335
Approved by: alexlarsson
Some apps, such as gnome-builder wants to access data from the
host, for instance in builders case the system includes. If you
have full filesystem access it is not really a loss of security
to also have /ect and /usr access, but for technical reasons
we can't expose them in the normal locations. However, we
can expose them in /run/host, so do that.
Closes: #1193
Approved by: alexlarsson
There's an oustanding bubblewrap PR where we'd like to change how
we set up the rootfs; a side effect of this will be that /newroot
disappears from the `/proc` links:
[bubblewrap pull 172](https://github.com/projectatomic/bubblewrap/pull/172).
I took a stab here at adapting the code to work in both the old and new cases.
Just compile tested at the moment. There's a lot of subtleties in this code; in
particular how we end up mutating-in-place the path buffer and how that
interacts with inspecting it.
Closes: #1063
Approved by: alexlarsson
This makes it easier to avoid typos, and also makes it easier to see
what groups and keys are in use. In the header file, they are
clustered according to the group in which the keys are used.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The compiler warning flag which was supposed to warn about this was not
being included in the CFLAGS for these targets. That will be fixed in an
upcoming commit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Changes to the Makefile could include changes to the options passed
to gdbus-codegen, which would invalidate the output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A rule of the form
foo.c foo.h: foo.in
some-generator --output=foo foo.in
is essentially equivalent to writing the same rule once for each target:
foo.c: foo.in
some-generator --output=foo foo.in
foo.h: foo.in
some-generator --output=foo foo.in
In a parallel build, this can result in some-generator being run more
than once with the same inputs and outputs, leading to unpredictable
results if the outputs are overwritten in-place by two parallel copies
(particularly if the generator does not use the standard atomic-writing
trick of writing out a temporary file and renaming it over the top of
the intended name, which gdbus-codegen does not).
gdbus-codegen happens to write the .h file before the .c file, so
use the real build rules to generate the .c file, and consider the
.h file to be a side-effect.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This was almost certainly meant to be a logical AND, not a bitwise one.
As spotted from compiler warnings.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows you to add multiple paths at the same time, plus
grant an app access to it, plus it returns the fuse mount path.
This allows you to avoid a lot of roundtrip in common cases.
Add an annotation that lets us pass an fd-list to
the generated wrapper around Add(). This is more
convenient than calling the method manually.
Currently, we have no callers for the wrapper, so
this does not affect any other code.
We're getting "fuse: copy from pipe: short read" from
libfuse and a broken filesystem with this. See
https://github.com/flatpak/flatpak/issues/570
I've tried to look into if this is fixable, but I can't
really find any way we could do things differently that
may help, so the fix is to disable spice_read.
fi->fh is a uint64, and if we cast that directly to a pointer
on a 32bit arch then we get a warning, so lets first cast
to gsize, and then to pointer.
Should fix https://github.com/flatpak/flatpak/issues/173
If the name is lost *and* the session bus is closed, we would
crash with an assertion failure when the GError is overwritten.
Signed-off-by: Simon McVittie <smcv@debian.org>
