- Refer to PolkitAgentSession in general instead of to _response only
 - Revert to the original description of authentication cancellation, the
   agent really needs to return an error to the caller (in addition to dealing
   with the session if any).
 - Explicitly document the UID assumption; in the process fixing bug #69980.
 - Keep documenting that we need a sufficiently privileged caller.
 - Refer to the ...Response2 API in more places.
 - Also update docbook documentation.
 - Drop a paragraph suggesting non-PolkitAgentSession implementations are
   expected and commonplace.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90837Reviewed-by: Colin Walters <walters@redhat.com>

http://lists.freedesktop.org/archives/polkit-devel/2015-June/000425.html

The "cookie" value that Polkit hands out is global to all polkit
users.  And when `AuthenticationAgentResponse` is invoked, we
previously only received the cookie and *target* identity, and
attempted to find an agent from that.

The problem is that the current cookie is just an integer
counter, and if it overflowed, it would be possible for
an successful authorization in one session to trigger a response
in another session.

The overflow and ability to guess the cookie were fixed by the
previous patch.

This patch is conceptually further hardening on top of that.  Polkit
currently treats uids as equivalent from a security domain
perspective; there is no support for
SELinux/AppArmor/etc. differentiation.

We can retrieve the uid from `getuid()` in the setuid helper, which
allows us to ensure the uid invoking `AuthenticationAgentResponse2`
matches that of the agent.

Then the authority only looks at authentication sessions matching the
cookie that were created by a matching uid, thus removing the ability
for different uids to interfere with each other entirely.

Several fixes to this patch were contributed by:
Miloslav Trmač <mitr@redhat.com>

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=90837
CVE: CVE-2015-4625
Reported-by: Tavis Ormandy <taviso@google.com>
Reviewed-by: Miloslav Trmač <mitr@redhat.com>
Signed-off-by: Colin Walters <walters@redhat.com>

Now to implement this in the interactive authority...

See https://bugzilla.redhat.com/show_bug.cgi?id=526053 for more details.

Also bump requirement on EggDBus to 0.6 (to be released later) for a
bug-fix with flag properties.

Also make this and other details available via methods on the
PolkitAuthorizationResult object.

See this and surrounding messages

 http://lists.freedesktop.org/archives/polkit-devel/2009-July/000189.html

for more information.

But only allow this if

 - the caller and the subject being checked is the same user
 - no details are passed (otherwise dialogs can be spoofed)

Also add a RevokeTemporaryAuthorizationById() method.

Also change how authentication agents are registered (take a Subject
instead of the session-id) and add convenience functions to
asynchronously construct a PolkitUnixSession object given a process id
(by querying ConsoleKit).

Also remove the ObtainAuthorization() call and allow apps to pass
details to CheckAuthorization.

Also add an example for this.

Also add a short example to test this.

The session_id has got to be empty for now. The thinking is that in
the future we might want to register an authentication agent that runs
in secure desktop, e.g. a separate session from the user session.

This will allow us, in the near future, to declare org.fd.PK1.Authority and
PolkitAuthority as stable while allowing changes to how we manage the (local)
authority even after 1.0.

Yay, it works!

Now to actually use them...

... also remove EnumerateSessions

Now to finish implementing the local files backend....

Also get rid of AuthorizationClaim type and add D-Bus prototypes for a
couple of other methods.

Now to port the XML parser and land it in polkitbackend so backends
can easily implement EnumerateActions().

Also port to use non-reffing structs in EggDBus HEAD.