In order to configure gnome-software to show specific apps in one region
without showing to all language speakers, we allow the storage of full
locales on the extra-languages key. However, these locales are ignored when
calling flatpak_installation_get_default_languages, so locales will be reduced
to their language identifier (eg. en_IN locale will be returned as 'en', and
az_Latn_AZ will be returned as 'az'). In order to get the full locales, we can
call flatpak_installation_get_default_locales instead, which can return languages
and locales.
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
Allow overriding $datadir/xdg-desktop-portal/portals using the
$XDG_DESKTOP_PORTAL_DIR env var. We will need this in the test suite when
we want to pass in our own (faked) portal implementation.
We add socat to the test runtime, and then we use that to run a
test app outside the sandbox as if it was inside.
The testcase connects creates a monitor and ensure we properly get signals
for updates.
This allows an application to request it to be updated to the latest version.
The updates are done out-of-process by re-spawning the portal (via
/proc/self/exe) and proxying the relevant events over a socket pair, in
order to avoid any long term stability or memory requirements from
running the update operation.
