This means sandboxes with dbus access can use portals etc, but they can't
talk to the main app, or impersonate it, but you can still use dbus and
well-known names to talk to them if needed.
It does mean however that if you use this, different sandboxes can see each
other on the bus, so be careful.
Uncrustify has an option "nl_func_var_def_blk" which is supposed to
ensure there's a newline character between the block of variable
definitions and the rest of the function body, but it gets confused and
thinks that the first instance of "g_autoptr" or "g_auto" being used on
a variable is the start of the function body. So this commit removes
those extra newline characters and removes that option in uncrustify.cfg
so they don't get re-added the next time uncrustify is run.
Here's the command I used:
perl -0777 -i -pe 's/\n(\n\s*g_auto\()/\1/g' `git ls-tree --name-only
-r HEAD | grep \\\.[ch]$ | grep -v common/valgrind-private.h |
grep -v app/flatpak-polkit-agent-text-listener\\\.[ch]`
I ran it again with "g_autoptr" in place of "g_auto", and made a few
manual edits to add back the newline when the g_auto* was in the middle
of a function body rather than at the top.
Closes: #2715
Approved by: matthiasclasen
Edit uncrustify.cfg to add options to remove extra newlines near opening
and closing braces, and run uncrustify again.
Closes: #2715
Approved by: matthiasclasen
Whenever we use $XDG_RUNTIME_DIR and expose it somehow in the sandbox
we fully resolve the path, because if (as happens on gentoo for instance)
it contains /var/run -> ../run, then flatpak thinks we need to
add the /var/run symlink in the runtime even though we already
exposed that.
Closes: #2710
Approved by: matthiasclasen
Now that we're moving away from a pure ASCII esthetic,
it looks odd to me to have a mixture of 3 dots and
proper ellipsis, so switch everything over to use
U+2026 instead of 3 dots.
Some minor other formatting and string changes
are included here as well.
Closes: #2454
Approved by: alexlarsson
The error messages here make it appear that values can
be prepended with a '!', but a few lines down we throw
an error if thats the case.
Closes: #2298
Approved by: matthiasclasen
In version 0.99.1 (065053775b) flatpak
stopped inheriting permissions from the runtime, because that made
the story about application permissions way to complicated. What
we want is to have a static set of permissions for the app that
is frozen at install time.
However, inheriting permissions from the runtime makes a lot of sense
as certain permissions are required from the runtime, in particular this
is used by the kde runtime to read the kdeglobals file, etc.
So, to combine the best of the two worlds, we now do inherit permissions,
but at build-time (and you can disable it if you want). This way
kde apps don't have to repeat themselves, but we still get static
application permissions.
Closes: #2230
Approved by: alexlarsson
flatpak_fail is a convenient shortcut, but falls short
for actual error reporting. Use proper G_OPTION_ERROR
error codes here.
Closes: #2150
Approved by: alexlarsson
SSH authentication sockets can be placed in a number of places, so it
is difficult for applications to just mount a fixed directory or
directories, hoping that SSH_AUTH_SOCK points somewhere inside the
mounted content.
Closes: #1764
Approved by: alexlarsson
Now that name.* matches the name itself we can simplify the default rule
from `--own=name --own-name=name.*` to just `--own-name=name.*`.
Closes: #1730
Approved by: alexlarsson
This gives access to AF_BLUETOOTH sockets in the seccomp rules. You additionally
need to give network access for the sockets to really work, because the
kernel doesn't (yet) namespace bluetooth sockets.
Closes: #1721
Approved by: alexlarsson
This also adds a call to this from flatpak build, although it is
not (yet) strictly necessary as all the flags it sets so far
are always set when building. This may change in the future though.
Closes: #1721
Approved by: alexlarsson
This moves all the files from lib into common, and it also adds all the libflatpak
sources into libflatpak-common, making libflatpak just a wrapper around the common
helper library.
This move allows the CLI to use all the code from libflatpak. We were already doing
this with a few things like flatpak-error*.[ch], and we want to do it even more
when sharing FlatpakTransaction. This also allows use to slowly move
the CLI to using the libflatpak apis for some things.
Closes: #1706
Approved by: alexlarsson
This uses FlatpakBwrap to simplify the setup of the dbus-proxy,
resulting in cleaner code, but also a better base for future work
to pass pre-created socket fds into the proxy instead of paths.
Closes: #1676
Approved by: alexlarsson
We will use this later to work out which .service files we can export
based on names that we are allowed to own.
Closes: #1589
Approved by: alexlarsson
This way we never get confused about which part of the argument
is the permission suffix, which could be exploitable if you can
control the --filesystem calls such as with sandboxed Spawns.
This runs the app in a very tight sandbox, with no access to anything
except /app and /run and some read-only host things like fonts and icons.
You can additionally add explicit permissions on the commandline,
like --share=network to actually grant some access.
This also sets $FLATPAK_SANDBOX_DIR to ~/.var/app/$appid/sandbox in the
environment.
On atomic /home is a symlink to /var/home, so when we bind-mount
the persistent directories we need to early-resolve the symlinks
to avoid running into issues with /newroot.
In most cases we do this already by calling flatpak_bwrap_add_bind_arg,
but the persistent dir case did not, because that function required
the target to exist, and the persistent directoried might not.
However, these days flatpak_bwrap_add_bind_arg is fine if the base
dir doesn't exists but the target does, which is the case here,
so we can use it now.
This fixes e.g. steam: https://github.com/flatpak/flatpak/issues/1278Closes: #1422
Approved by: cgwalters
This means use x11 if no alternative is present, and should be used
for applications that support both X11 and wayland, but want to be
sandboxed when running under a wayland compositor (but still want to
run under an X server).
Closes: #1416
Approved by: alexlarsson
This is now in xdg-desktop-portal. We keep a version of the document
portal dbus XML so that we avoid weird build dependencies.
Flatpak itself is technically not dependent on the document portal,
but it is very much recommended that you use it.
Closes: #1398
Approved by: alexlarsson
Since flatpak_export_paths_export_context and flatpak_exports_from_context
are now in flatpak-context.c we make them begin with flatpak_context_
Closes: #1374
Approved by: alexlarsson
