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
