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