Comment 10 for bug 1299146

In terms of fixing this, I think the following is needed in order to enable keystone v3 with swift. Note that the proposed changes would be confined to the keystoneauth middleware and apply only when operating in a keystone v3 regime.

1. Prohibit the creation of new swift container ACLs using the 'legacy' keystone cross-tenant ACL syntax (i.e. <tenant>:<user>). Usernames are no longer unique across v3 keystone domains and this syntax is not capable of expressing domain qualified user names because there are no reserved characters that can be used as a delimiter between the domain and user parts e.g. <user>@<domain> is not suitable.

2. Legacy ACLs that *already exist* on containers created under the v2 keystone regime can still be applied IFF the requesting user and the account are in the default v3 domain. The account can be assumed to be in the default domain because the legacy ACL must pre-date v3 migration, and the user's domain is added to the request context by authtoken middleware when validating against a v3 API.

3. All new ACLs, and modifications to existing ACLs, must be made using a new ACL syntax that supports domain-qualified user names. Any container POST having an X-Container-[Read|Write] that does not conform to the new ACL syntax should be rejected. (With resellerAdmin requests it may not be possible for swift to determine that the target of a POST is in the default domain and so we must prevent creation of any further legacy ACLs in order to enforce the assumption under item 2).

4. A new ACL format should be provided using JSON to express explicit user, project and domain name/id parameters. The syntax could be similar to swift's account ACLs.

For existing operators that have a need to adopt v3 keystone and need to map *existing* accounts to multiple v3 domains, a keystoneauth config option could be provided to override the above prohibitions and continue to apply legacy ACLs regardless of user/tenant domain. In doing so the operator should be sure that usernames are guaranteed to be globally unique in their system otherwise they remain vulnerable to the original issue.

We are working on a patch.