This policy will allow users to modify their personal connections (ie
maybe VPN connections, etc) distinctly from system-wide connections that
affect more than just their user. It makes sense to be more lenient when
making changes to settings that don't affect other users.
Meaning stays the same, but this will allow us to differentiate
in the future between personal connections (ie, just visible to
one user) and system connections (visible to more than one user).
Moves the system settings permissions checking into the core service's
permissions checking, which at the same time enables 3-way permission
reporting (yes, no, auth) instead of the old yes/no that we had for
system settings permissions before. This allows UI to show a lock
icon or such when the user could authenticate to gain the permission.
It also moves the wifi-create permissions' namespace to the main
namespace (not .settings) since they really should be checked before
starting a shared wifi connection, rather than having anything to do
with the settings service.
Since these were properties they are harder to validate the caller as
dbus-glib doesn't have any hooks before the property is set. So we
install a low-level dbus filter function to catch property Set
requests before they get to dbus-glib and handle the property access
there.
Remove all references to connection scope and user-settings services
from the various internal APIs of the daemon. The external DBus API
remains unchanged, albeit in stub form for scope stuff.
Default to 'not allowed', distros that need backwards compatibility
can flip this to 'yes' if they need to. At this point, only power
management scripts should call these functions.
