Note that this permissions check only concerns parental controls. If the
system flatpak polkit policy disallows installation to the system repo
(or requires an administrator password for it), this setting cannot
override that.
The default was previously to disallow installation, because the flatpak
polkit policy was previously overridden by these settings. How parental
controls are checked in flatpak has evolved since then, though.
See: https://github.com/flatpak/flatpak/issues/3995
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Replace usages of the terms whitelist and blacklist with the more
inclusive and more precise terms allowlist and blocklist, which are
actually also more consistent with parts of the codebase, e.g.
mct_app_filter_is_content_type_allowed().
The only API break here is in libmalcontent/app-filter.h but the
relevant API is not used anywhere else in Endless OS beyond this repo,
nor to my knowledge in any other distribution. Also, per the README,
this project's API is not stable, so now is a good time to make this
change.
This will store information about the user which is related to parental
controls. Currently, that’s just a boolean indicating that the user is a
parent, and hence that their account should be presented differently in
UIs.
See: https://gitlab.gnome.org/GNOME/gnome-initial-setup/issues/94
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This is another extension interface on accountsservice which stores
information about time and usage limits on the user session. Currently,
only a ‘daily schedule’ limit (or no limit) is supported, but additional
types and combinations of limits can be supported in future.
The daily schedule limit allows using the computer between a certain
start time and end time each day (the same each day). The user will be
kicked out of their session when the end time is reached, if they
haven’t already logged out.
This includes the getters for the new data, polkit rules for accessing
it, and some documentation. Changes to `malcontent-client` to support
session limits, setters, and unit tests will all follow.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When logged in as an administrator, and editing other user accounts in
gnome-control-center, polkit keeps popping up authentication dialogues
to read or change other users’ parental controls data. That shouldn’t be
necessary since we’re an admin user, and it’s not a critical enough
action to need to prompt the admin to re-authenticate to make sure they
really want to make such changes.
Add a .rules file to squash the polkit prompts for reading other users’
parental controls. Keep the default policy of auth_admin_keep for
changing our/others’ parental controls, since that should be handled by
the ‘Unlock’ button in g-c-c.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23897
That’s what’s more conventional for D-Bus properties, and we really
should have used CamelCase from the beginning.
See the advice on
https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties:
> Strictly speaking, D-Bus property names are not required to follow
> the same naming restrictions as member names, but D-Bus property
> names that would not be valid member names (in particular,
> GObject-style dash-separated property names) can cause
> interoperability problems and should be avoided.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This controls whether the user can install to their user repository at
all; if it’s true (the default), then installation of apps is still
subject to the OARS filter.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24457
This is in preparation for adding a second boolean for the flatpak user
repository. Make the existing allow-app-installation boolean control
permissions for the flatpak system repository.
Having one boolean for each repository means we can allow users to
install to their user repository by default (subject to OARS ratings),
but not be allowed to install to the system repository.
While changing the name and semantics of the boolean, flip its default
value from True to False. Rather than letting any non-admin user install
new apps by default (subject to OARS restrictions), re-limit it to admin
users and users whose allow-system-installation key has been explicitly
set to True by the admin.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24457
This is a boolean preference which overrides the OARS values entirely if
FALSE.
This change breaks ABI for EpcAppFilterBuilder, but since that hasn’t
been used in any code we’ve shipped yet, that should be OK.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24457
Even though I can’t find a single copy of the specification or how it
differs from oars-1.0; it allegedly exists.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23999
Use accounts service’s vendor extension support for storing the app
filter per user, in a way that persists and which access to is
controlled by polkit (so writes can be restricted to administrators).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23858
Philip Withnall
Sergey Shatunov
Matthew Leeds
Philip Withnall