Bump our GLib dependency to 2.60 so we can use `gdbus-codegen
--interface-info-{body,header}` to generate interface definitions
dynamically rather than hand-coding them.
We actually need to depend on 2.60.1 so we get
https://gitlab.gnome.org/GNOME/glib/merge_requests/721.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When run with `--quiet`, the `check` subcommand will now print nothing.
It continues to exit with an appropriate exit status.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Create a new MctManager object which is used as the anchor for getting
or setting MctAppFilters.
This changes the API naming around quite a bit, but doesn’t really
change its behaviour or functionality — see the tests for examples of
how little things change.
This is one step on the way to emitting a signal (from MctManager) when
a user’s parental controls change.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.freedesktop.org/pwithnall/malcontent/issues/1
This indicates that app filtering is disabled globally, perhaps because
it’s not installed in accountsservice properly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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>
Philip Withnall
Philip Withnall
Georges Basile Stavracas Neto