Swift with keystone auth does not allow ACL on a Tenant (or Account)

[Daniel Curran]

I was doing some testing and making sure the ACL's for my swift install worked. I created an admin user, a regular user, two containers and 2 or 3 objects per container. The first container/object was supposed to have admin only priveleges and the second would allow users from a certain tenant. I tested applying these with both cmd line and api calls and got the same result.

Assume:
tenant name = myTenantName
regular user name = myUser

I set the container headers to:
            {'X-Container-Read': 'myTenantName', 'X-Container-Write': 'myTenantName'}

Then I try to do actions such as list objects or update metadata but get forbidden errors.
I also tried:
            {'X-Container-Read': 'myTenantName:', 'X-Container-Write': 'myTenantName:'}
            {'X-Container-Read': 'myTenantName:*', 'X-Container-Write': 'myTenantName:*'}
but none of them work.

Eventually, I had to specifically set them for each user as follows:
           {'X-Container-Read': 'myTenantName:myUser', 'X-Container-Write': 'myTenantName:myUser'}
According to the doc my very first set of headers should work. Speaking to some people on the IRC channel I found it's possible that this has to do with the fact that swift uses hash keys to decide ACL permissions. Perhaps the tenants from keystone don't get mapped properly or at all.
I can't find any other bugs relating to this so I'm not sure if it's a known issue without a plan for a fix, hasn't been mentioned yet or if I'm bad at swift.

Any feedback is appreciated and if any more info is needed I'll be happy to provide it.

[Kun Huang (academicgareth)]

Hi,

Actually, {'X-Container-Read': 'myTenantName:myUser', 'X-Container-Write': 'myTenantName:myUser'} is the correct header for you. In authorizing codes, only about 10~20 lines control the acl access which is easy to check but lack of flexibility. Such as your myTenantName:* is a common writing but doesn't work now.

I'm not sure core developer's plan, but I could write a patch for this case "myTenantName:*".

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/22820
Committed: http://github.com/openstack/swift/commit/58a095b93e1e6f742e619a100e8cec693bc41dad
Submitter: Jenkins
Branch: master

commit 58a095b93e1e6f742e619a100e8cec693bc41dad
Author: Kun Huang <email address hidden>
Date: Tue Mar 26 13:20:09 2013 +0800

    Improve swift's keystoneauth ACL support

    Below three bug reports talk about one thing.
    Current keystoneauth ACL supports as:

    tenant_name:user_id ok
    tenant_name:user_name no
    tenant_name:* no
    tenant_id:user_id ok
    tenant_id:user_name no
    tenant_id:* no
    *:user_id ok
    *:user_name no
    *:* no

    This patch will make all of above work fine.
    Applying (tenant/user)name could let user put or get their data in a
    more readable way. The tenant_name:* and *:user_name is suitable for
    many usage.

    note: to keep compatibility here add a new keystone.identity just for
    authorize() itself and leave env['keystone.identity'] to other
    middlerwares.

    Fixes: bug #1020709
    Fixes: bug #1075362
    Fixes: bug #1155389
    Change-Id: I9354dedaad875117f6a9072c67e9ecf69bfca77e