Comment 4 for bug 1642669

This is not a simple problem.

In essence, policykit was designed so that a privileged program can offer services to unprivileged programs. When an unprivileged program talks to the privileged program over dbus, the privileged program talks to the policykit DBus service and asks if this is ok. Policykit might say yes, no or prompt. policykit is really just a dbus system service which has a database of files that are used to declare the authorizations for polickit-aware services. Eg, policykit policy is used on classic for things like allowing users in the 'sudo' group to change the timezone or add a printer without a password (eg, an application in the user's session application talks to a DBus system service, the system service asks policykit what to do, and the system service enforces the decision).

In terms of policykit and snappy:
- policykit is not (currently) included in the core snap
- policykit is designed for use in graphical environments (for the prompting)
- policykit can have policy that does not require prompting (eg, by uid, group, specifying allowed/disallowed DBus APIs, etc)
- policykit overlaps in some ways with snappy interface connections. Some important differences are that a) the system DBus services enforce the policykit policy as opposed to an external sandbox mechanism (eg, AppArmor) and b) policykit allows for contextual runtime password prompting

To fix this bug properly, there needs to be careful design. Eg, how does policykit fit in a snappy world? When should policykit be used? Should policykit be in the core snap or a slot snap? Should there be a policykit interface backend? If policykit is in a slot snap, how do we conditionally use the policykit interface backend only when the slot snap is installed? Should we adjust the interfaces for existing policykit-aware slot implementations like bluez and network-manager to use the policykit backend? Will those policykit-aware slot implementations require policykit be available (via core or snap)? How do we deal with prompting when there isn't a graphical environment? How will policykit policy affect the base declaration? On security policy? (eg, maybe something is ok to auto-connect if policykit policy makes things safe)? IIRC, Ubuntu Touch only had policykit policy that did not require prompting but in the era of unity8 on classic systems vs unity8 on all snaps systems, what effect (if any) is there on the policykit policy? Instead of policykit itself, should we have a service that speaks the policykit DBus API call out to snapd for authorizations instead of using policykit files similar to how the new trust-store design will call out to snapd instead of managing its own trust-store? Should we use a combination of snapd and policykit? Etc, etc

Since policykit in core or as a snap requires very careful thought and design and unity8 is blocked on this bug, I suggest:
- create a unity8-policykit interface in snapd
- unity8 snap ships policykit as a dbus system service and it ships all the policykit files it cares about (this will include things like network-manager). In this manner any services that unity8 ships can talk to the dbus system policykit service it ships, but nothing else can

This should unblock the unity8 team but has several difficulties:
- unity8 snap on classic is going to have trouble with the host policykit on classic
- the above doesn't allow for anything other than unity8 DBus services to talk to policykit. Eg, the network-manager snap would continue to not talk to policykit
- things unravel fast as soon as another snap like network-manager wants to use the policykit in unity8 (which gets back to how this should actually work needs design)