Historycally the system helper has been running in a generic
unconfined_service_t domain. However, this caused problems with the
new revokefs support, because passing the revokefs unix domain socket
over the system bus got it kicked of the bus, because to do this
dbus-daemon needs rw rights to the socket.
So, this module creates a custom domain flatpak_helper_t, which
allows us to add special permissions to dbus-daemon to allow
access to its sockets.
The domain is otherwise uncontained just like before. I did try
to make it contained, but that is a lot of work as the permissions
it needs are very complex.
Note to packagers on selinux systems, for flatpak to work well
you need to install this module and relabel the system-helper
binary.
In my testing on fedora I used something like this:
%post
%selinux_modules_install %{_datadir}/selinux/packages/flatpak.pp.bz2
%postun
if [ $1 -eq 0 ]; then
%selinux_modules_uninstall %{_datadir}/selinux/packages/flatpak.pp.bz2
fi
With these new files:
%{_datadir}/selinux/packages/flatpak.pp.bz2
%{_datadir}/selinux/devel/include/contrib/flatpak.if
Closes: #2657
Approved by: alexlarsson
This adds a new helper method "GetRevokefsFd" which is responsible
for spawning the backend part of the revokefs filesystem. It takes care
of creating a cache location for the backing directory in repo/tmp.
This cache location is transferred over D-Bus to the client with the
other end socket fd.
The client on receiving the socket fd creates a mountpoint directory and
spawns the revokefs-fuse filesystem. It then creates a child repo for the
pull. In any case of failure, it fallbacks on the current code path
(which causes temporary duplication of files on disk).
The backing dir itself and all files written to it by the revokefs-fuse
backend process are owned by the "flatpak" user. After the pull in the
child repo is completed, it's ownership is then canoncalized with owner=root
and permissions as per bare-user-only in Deploy().
Now we have fulfilled all the criteria to hardlink the child repo into
the system one and avoid duplication. See [1].
If there is existing cache directory available in repo/tmp, it will be
mounted using revokefs-fuse for the current pull. Hence, it is possible
to recover the previous partial pull which might have failed due to some
error.
[1] https://github.com/ostreedev/ostree/pull/1776Closes: #2657
Approved by: alexlarsson
This is a script that program that gets run by systemd
before every user service to set up the environment.
See systemd.environment-generator(7) for details.
Closes: #2122
Approved by: matthiasclasen
This adds a --enable-coverage configure option and a
coverage target to generate coverage testing for
the testsuite. The generated html ends up in the
coverage/ directory.
Closes: #2187
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 listens to org.freedesktop.portal.Flatpak and lets flatpak
sandboxes do flatpak specific things.
Initially this only allows access to "Spawn", which lets you start a
new copy of the current or latest version of the calling app,
optionally with sandboxing.
This allows the app to re-start itself with the latest version after
an update, and the sandboxing is useful for apps that want to manually
sandbox part of themselves.
You can also expose one or more subdirectories of
~/.var/app/$appid/sandbox/ to the app, read-write or read-only. This is
useful to communicate with the sandbox.
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
Followup to the previous commit to use `O_TMPFILE`, for
the cases here what we really want is to use sealed memfds. This
ensures the container can't mutate the data we pass.
Now, the args fd I was looking at turned out to be a bwrap bug,
but this is a good example of the mitigation:
```
$ flatpak run --command="/bin/sh" org.test.Hello
ls -al /proc/$$/fd
total 0
dr-x------. 2 1000 1000 0 Oct 1 16:43 .
dr-xr-xr-x. 9 1000 1000 0 Oct 1 16:43 ..
lrwx------. 1 1000 1000 64 Oct 1 16:43 0 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 1 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 2 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 255 -> /dev/pts/2
lrwx------. 1 1000 1000 64 Oct 1 16:43 9 -> /memfd:bwrap-args (deleted)
org.test.Hello$ echo foo > /proc/self/fd/9
sh: /proc/self/fd/9: Operation not permitted
```
Closes: #1064
Approved by: alexlarsson
This is the first step in increasing the startup performance for
font use in flatpak. Right now every app has its own cache
for the system font dirs, which means they must be fully regenerated
the first time the app starts.
With this we now expose the host system and per-use fontconfig caches
in the sandbox (read-only). This allows the sandbox to re-use caches
from the host, if the runtime fontconfig configuration is correct.
Unfortunately, this doesn't currently work, because the font caches
are looked up based on absolute paths to the font directories and they
are different in the host and the sandbox. There is some work in
progress to fix this in fontconfig here:
https://bugs.freedesktop.org/show_bug.cgi?id=101889
It uses inline for loop initialisers, which are a C99 feature. Set
-std=gnu99 like ostree.git does for its libglnx submodule.
Based on a patch by Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.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>
This ensures it’s always included in the build, regardless of whether
someone forgets to #include it from a C file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In ostree I maintain what I consider a "baseline" set of compiler
warnings that should *always* be fatal for a modern C project.
I noticed while working on a previous patch that a `-Werror=format`
warning wasn't fatal.
There are a few that are really, really important like
`-Werror=missing-prototypes`. I also take some like `-Werror=misleading-indentation`
which already caught some bugs. See also https://lwn.net/Articles/678019/
The CLI is pretty similare to the `git bisect` one and works as follow:
$ flatpak-bisect org.app.App start # Update application and get the history
$ flatpak-bisect org.app.App bad # Sets current commit as first bad commit
$ flatpak-bisect org.app.App checkout GoodHash # Checkout the first known good commit
$ flatpak-bisect org.app.App good # Sets GoodHash as first good commit
... Here it starts bisection and checkouts a commit on the way, the user should launch the
app to check if the commit is good or bad and run:
$ flatpak-bisect org.app.App good # if commit is good
$ flatpak-bisect org.app.App bad # if commit is bad
flatpak-bisect will tell when the first bad commit is found.
Fixes https://github.com/flatpak/flatpak/issues/530
If EXTERNAL_INSTALL_DIR wasn't defined (which is likely, since nothing
in the build system does), then we would tell the system helper
to search /exports/share, which is not Flatpak's territory
(but is a semi-commonly-used path for site-specific NFS shares,
which might have contents that are inappropriate to search here).
Installations that do define an external installation directory
(Endless OS?) can easily override the Environment to include it
by placing a drop-in in
/etc/systemd/user/flatpak-system-helper.service.d/external.conf
or similar.
Typically Linux distributions employ /etc/profile.d for system wide
environment manipulation prior to multi-user initialisation. Modern
distribution efforts split the vendor configuration from the local
sysadmin configuration and data, by not using the /etc/ directories,
for example.
To enable this stateless pattern, this change adds a new --with-profile-dir
option to use an alternative location, such as within /usr/share/. This
ensures that the data (not configuration) is owned through the update
process, and does not conflict with changes made locally to the system,
enforcing domains of ownership.
To preserve backwards compatible behaviour, the default directory remains
set to /etc/profile.d.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
flatpak currently installs a gdm env.d and a bash profile.d file to
ensure XDG_DATA_DIRS is set to the right value. Neither is sufficient
when the dbus daemon is activated as a system --user service.
This commit adds a dbus service file snippet to frob its environment
variable for that case.
When the document portal is called from within the sandbox with an
app-private file path, translate the path to a document portal URI in
order to make it available to other applications.
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>
We shouldn't install .test metadata for these, and run them as TAP
test scripts. In glib-tap.mk jargon that makes them "extra scripts".
Signed-off-by: Simon McVittie <smcv@debian.org>
As explained in bubblewrap commit f6ca3690, libraries should
always go in LDADD and not LDFLAGS, because the order of arguments
to the linker matters. Many distributions' linkers are tolerant
enough that it doesn't matter in practice, but it matters for
static linking, and it might also matter on Ubuntu.
Signed-off-by: Simon McVittie <smcv@debian.org>
Listing variables whose values are conditional in EXTRA_DIST is
problematic: if Flatpak was configured without installed-tests,
we would not distribute those files. This is a problem during
distcheck, where installed-tests are disabled.
For files not placed in a special subdirectory, glib-tap.mk handles
this for us. For the keyring and the databases, we have to do it
ourselves, by arranging for them to be in a dist_ variable that is
special to Automake - when determining what to distribute, Automake
includes anything that is selected for distribution under any
combination of conditionals.
While I'm here, include test keyring's README in tarballs: its advice
is equally applicable in a tarball release.
Signed-off-by: Simon McVittie <smcv@debian.org>
According to the FHS, applications which place internal libraries in
/usr/libexec should not also use /usr/lib for this purpose:
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
As several flatpak helpers are already installed in libexecdir, move
the bwrap helper to /usr/libexec/flatpak-bwrap.
