An issue was reported indicating that in some cases, the stated behavior of the
default policy being added to tokens unless specifically requested could lead
to a privilege escalation scenario if the parent token did not itself have the
default policy. In most cases (e.g. using the default default policy) the
escalated privileges are unlikely to be dangerous, but this behavior is
undesired.

As such, we have modified the rules around default in a few ways when
creating tokens using this endpoint:

If a token creation request does not specify desired policies, the parent's
policies will be used (as normal) but default will not be automatically
added, so the child token will only have default if the parent does

If a token creation request specifies desired policies, default will be
added automatically if and only if the parent token has default

If the parent token has sudo capability on the token creation endpoint,
default is always added; since sudo capability on this endpoint allows
adding any policy, this is not privilege escalation with respect to the
parent token-holder

When using token store roles, default is always added to the list of child
token policies unless default is contained in disallowed_policies

Regardless of provenance, if a token being created has the default policy
and no_default_policy has been set true for the request, the default
policy will be stripped from the final set of policies.

While investigating a report of accessor entries not being removed correctly
from Vault's data store, a security issue was discovered: if limited use-count
tokens are being used and expire due to the use-count dropping to zero (rather
than due to the token's TTL expiring or the token being explicitly revoked),
several pieces of Vault's token revocation logic would not be properly run.
This included cleaning up the associated accessor entry from the data store,
but more importantly, included the logic used to immediately expire leases
associated with the token.

These leases would not live forever; they would still be expired when their TTL
ran out. This limits the severity of this issue, but it is still a potentially
serious bug depending on each particular operational scenario.

To mitigate this issue we have taken the following steps:

Updated the token revocation logic to be more resilient to failures that can
happen as it performs its various steps; the revocation will now properly
only be considered successful if no error has occurred. In addition, the
token entry will remain in the data store (but not be usable for
performing Vault functions) until all aspects of revocation report success,
allowing future revocation requests to succeed if the underlying cause of the
failure has been addressed.

Added a function auth/token/tidy that can both clean up the leaked
accessor entries and expire the leases associated with those accessors'
tokens.

In most cases, running auth/token/tidy should expire all outstanding
leases that were generated by these revoked limited-use-count tokens.

If you are both using limited-use-count tokens and you are using them to
issue leased secrets, you should consider upgrading to 0.6.4 and running the
auth/token/tidy endpoint immediately. Please note that running this function
involves a lot of requests to the data store, so plan load accordingly.

Note: response wrapping tokens do not allow generating leases but have still
been subject to leaking the accessor entries, so if you have been a heavy user
of response wrapping you should still consider running the tidy function.