Note that this change breaks backward compatibility when handling
flatpak refs/IDs if the passed argument also resolves to a valid path,
in which case an exception will be raised.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
The cmdline arguments may refer to both paths or flatpak refs so lets
disambiguate here for clarity.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
This is useful for example if blacklisting all apps that can
handle certain content types is desired.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
The filter blacklist also holds information on flatpak refs that are
blacklisted (apart from paths), so lets rename it for clarity.
Signed-off-by: Andre Moreira Magalhaes <andre@endlessm.com>
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
Andre Moreira Magalhaes
Philip Withnall
Philip Withnall