This writes temporary files needed for .xauth and seccomp to /tmp
rather than /var/tmp. This is useful because /tmp is more likely
to be tmpfs, and thus not run into diskspace issues.
This ensures that when the operation to install the app completes, the
app is ready to run — rather than having to wait for subsequent
operations to install extensions which the app depends on (such as
content, or locales).
This fits in with the current ordering for *un*installing apps, where
the main app is uninstalled first, followed by its extensions.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/issues/3017
Files in the srcdir need to be explicitly prefixed as such in rule
commands. This fixes `make install` when installed-tests are enabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This fixes compilation with GLib 2.63’s `gdbus-codegen`, which
automatically enables Unix FD support for D-Bus APIs which use the `h`
type, even if the `org.gtk.GDBus.C.UnixFD` annotation is missing.
By adding the annotation, the generated header whether using
`gdbus-codegen` 2.63 or < 2.63.
This is a slight API break in GLib, but it’s questionable about whether
flatpak should have always had the annotation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than this weird shell loop with a timeout and polling we
move the httpd spawning entirely into the python code, and use
a pipe to synchronize the spawning. This way we can also use
the shell job control to properly clean up any running processes
from the test suite.
Additionally, this adds some (lame) support for token handling in the
test webserver, where you for any file foo can create a foo.need_token
containing a token that is needed for that file.
FlatpakTransaction inherently doesn't differentiate between a
autoupdate and a regular update; both are
FLATPAK_TRANSACTION_OPERATION_UPDATE.
This getter can help differentiate between a regular update
and autoupdate in clients like gnome-software. Autoupdates
work in two separate transaction passes; first that runs with
"no-deploy" and the second pass that deploys all the downloaded
update (i.e. with "no-pull").
These are from paid-for translations from Endless’ downstream copy of
flatpak. I don’t know the original authors, and don’t know if the
translations are correct. (They should be though.)
Probably better than having no translations for these strings in
upstream flatpak, for the moment.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will be used for parental controls, and potentially other reasons
for denying installation of an app.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Use the user’s OARS filter to prevent installation or upgrade of
apps which have more extreme content than the user is allowed to see.
This uses libmalcontent to load the user’s enforced OARS filter, which
describes the extremeness of each type of content the user is allowed to
see. If an app they are trying to install exceeds the filter value in
any OARS section, installation is disallowed and an error is returned.
libmalcontent stores the parental controls policy per-user in
accountsservice, which enforces access control on the policies.
The app filter is also allowed to prevent app installation entirely,
which overrides the OARS values. This is independent from the app-install
polkit action, which determines whether an unprivileged user may install
an app system-wide. Being stored in accountsservice, the new boolean is
also easier to set per-user without having to programmatically write a
polkit JS policy file which handles multiple users (and parse it back
again).
The parental controls checks are done at deploy time, either in the
`flatpak` process (for user repositories) or in the
`flatpak-system-helper` (for system repositories). The checks use
content rating data extracted from the app’s AppData XML and stored in
the `FlatpakDeploy` cache. The checks are passed through polkit (even
for user repositories) so that users can get an admin override to
install apps which would otherwise be too extreme. This uses the new
`org.freedesktop.Flatpak.parental-controls` polkit rule.
The checks have to be done at deploy time, as that’s when the AppData
XML for the app is parsed. The downside of this arrangement is that an
app must be entirely downloaded before the parental checks can be done.
This won’t be much of an issue on normal desktops, however, since we can
assume that gnome-software will check an app’s appropriateness before
showing it to the user in the first place.
Parental controls are not enforced for non-apps/runtimes, which includes
the ostree-metadata and appstream/* refs.
One thorny issue is that flatpak unit tests may be run in an environment
with no system D-Bus available to connect to (a Jenkins instance, for
example), which means the call to `mct_manager_get_app_filter()` in
`flatpak_dir_check_parental_controls()` fails.
So this commit skips the parental controls check if the system bus is
unavailable and the environment variable
`FLATPAK_SYSTEM_HELPER_ON_SESSION` is set, since the testlibrary already
sets that variable so that the system-helper will be started on the
session bus.
The feature can be tested using something like:
```
$ malcontent-client set philip \
violence-realistic=none app/org.freedesktop.Bustle/x86_64/stable
App filter for user 1000 set
$ flatpak run org.freedesktop.Bustle
error: Running app/org.freedesktop.Bustle/x86_64/stable is not allowed by the policy set by your administrator
$ flatpak --user install flathub io.github.FreeDM
error: Failed to install io.github.FreeDM: Installing app/io.github.FreeDM/x86_64/stable is not allowed by the policy set by your administrator
```
Includes work by André Magalhães and Umang Jain.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This will be used in upcoming commits to enforce parental controls on
app installations.
We extend version 2 of the deploy data format because it has not
appeared in a release yet.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/pull/2797
Prevent the user from running a flatpak app if that app is filtered by
the parental controls applied to the user.
If flatpak is running as a system user (UID < 1000), ignore failure to
load the app filter. This could happen if a flatpak is run in the
gnome-initial-setup session, before the user’s account is created.
Includes contributions by André Magalhães.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/pull/2797
Also sort CFLAGS alphabetically. This will reduce the likelihood of
merge conflicts in future. This assumes the libraries and CFLAGS are
independent of each other.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rather than unlinking and symlinking the new value we symling into
a temporary name and then atomically renames on top of the (possibly)
pre-existing file.
This has two advantages. First it is atomic, whereas the previous code
could end up removing the old code without creating the new one, and
secondly this will generate a move inotify event which is what dbus-broker
uses to detect changes in the services file directory.
Fixes https://github.com/flatpak/flatpak/issues/3145
