This is an API break for the mct_{get,set}_app_filter() APIs, but makes
them a bit clearer to use, and a little more future proof.
This includes updates to all the tests and documentation.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Rename the library from libeos-parental-controls to libmalcontent, and
the client from eos-parental-controls-client to malcontent-client.
This was done using the following mechanical edits, and no other
changes:
```
git search-replace -f EPC///MCT
git search-replace -f Epc///Mct
git search-replace -f epc///mct
git search-replace -f eos_parental_controls///malcontent
git search-replace -f eos-parental-controls///malcontent
git search-replace -f EosParentalControls///Malcontent
git search-replace -f 'eos\\-parental\\-controls///malcontent'
git search-replace -f 'Since: 0.1.0///Since: 0.2.0'
```
Note that the accounts-service extension interface has *not* been
renamed, as that would revert people’s parental controls settings in
existing deployments.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This a relic from being hosted in Endless’ GitHub, and being built
directly for Debian. There’s no need to carry this upstream —
distributions can add their own packaging as needed.
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
When querying for the details of a particular user by their UID, we call
accountsservice over D-Bus. Its API takes a gint64 variant, which we
build using g_variant_new(), which takes varargs. Passing an integer of
type uid_t in the varargs works fine on 64-bit architectures, where
uid_t is 64-bit, but not on other architectures, where it’s likely
32-bit. In that case, g_variant_new() will still read 64 bits from the
varargs input, even though the caller only put 32 on there. The rest
will be filled with rubbish.
Fix that by explicitly casting the uid_t to gint64 in the varargs. Fix a
few other areas where uid_t variables are passed to functions which
might interpret them as a different kind of integer too.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24016
If the tests are linked to it dynamically, they won’t run without it
installed system wide, which is not what we want.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24004
These test get/set behaviour of EpcAppFilter, GAppInfo support, and
various error handling paths and corner cases.
With these tests, coverage of app-filter.c is:
• Lines: 97%
• Functions: 100%
• Branches: 57.5%
The branch coverage is not correctly reported, as it factors in the
failure branches for g_return_if_fail() precondition assertions, which
we deliberately do not test. With those branches manually excluded,
branch coverage is around 89% instead.
This adds libglib-testing as a subproject dependency, for its
GtDBusQueue. It adds gio-unix-2.0 as a dependency of the app-filter
tests, in order to be able to construct GDesktopAppInfos.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24004
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>
Previously, a caller-provided custom GDBusConnection was dropped on the
ground.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24004
A variable was being initialised self-referentially, which broke
handling of the X-Flatpak-RenamedFrom key.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24004
It was a string in GVariant text format, not a GVariant format string,
so should have been passed to the parse function.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24004
Since we ported to using FindUserById, it returns an explicit Failed
error if a user doesn’t exist. Previously, we would guess at the user’s
object path and call a method on it, and would receive a D-Bus ‘method
not found’ error in response if the user didn’t exist.
Correctly handle the explicit error from FindUserById.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24004
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 wrapper around the existing blacklist checking APIs which
binds them to specific keys in a #GAppInfo.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24017
These are the app-specific part of a flatpak ref, and are what’s
available when you have a .desktop file, via the X-Flatpak key in the
.desktop file. For example, for a flatpak ref
‘app/org.gnome.Builder/x86_64/master’, the app ID is
‘org.gnome.Builder’. It makes sense that we’d want to match against app
IDs in some situations, since the user probably doesn’t care about the
architecture or branch of the app they want to proscribe.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24016
Previously we just printed whether the filter was successfully
retrieved, since there weren’t any non-parameterised getter functions on
EpcAppFilter. Now we have some of them, we can print details of the app
filter.
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
It didn’t match the C file, so was causing a gtk-doc warning. Fix that.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24024
Allow the set of OARS sections set in a filter to be queried.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24024
Instead of manually constructing the D-Bus object path representing a
user, call FindUserById to have accountsservice do it for us. For normal
users, this makes no difference. For system users (UID < 1000) or other
users which accountsservice considers uninteresting (see
user_classify_is_human() in user-classify.c in accountsservice), no
D-Bus objects are created for them automatically. Calling FindUserById
ensures that the object is created before its path is returned to us.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24302
This should not introduce any functional changes, but does simplify the
code.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24024
Refactor the asynchronous implementation to run the synchronous
implementation in a thread. The synchronous version seems to be what’s
needed for most callers.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24024
Philip Withnall
Philip Withnall
Georges Basile Stavracas Neto
Will Thompson