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
As well as handling paths on the file system, we should allow flatpak
refs to be explicitly handled in the app filter.
Both refs and paths can be stored safely in the same app filter GStrv
because paths are always absolute and refs always start with ‘app/’ or
‘runtime/’.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24020
This allows the app filter to be set, using the new library API for it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24025
This includes some basic tests. Full test coverage has not yet been
achieved.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24025
Make it a bit clearer that it gets the bus purely for the getter method
for parental controls, which it is hard-coded to chain to.
This will clarify some later changes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24025
This allows the app filter to be set, using the new library API for it.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24025
This includes some basic tests. Full test coverage has not yet been
achieved.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T24025
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
This basic support will return the value of a given OARS section to the
caller.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23999
The OARS filter for a user will allow the administrator to define the
maximum levels of violence, alcohol, sex, location sharing, etc. that
apps may have in order for the user to be allowed to see them in app
listings or install them. Anything more intense will be hidden and
uninstallable.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23999
This commit is mostly to put the test framework in place, and create a
placeholder test library for libeos-parental-controls for packaging.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23859
This allows querying of the parental controls for a given user (or the
current user).
Includes documentation but no tests yet.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23859
This allows the app filter to be queried, and includes all the basic
parts of a shared library. Introspection and unit tests are to follow.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://phabricator.endlessm.com/T23859
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
Georges Basile Stavracas Neto
Philip Withnall
Philip Withnall
Will Thompson