Multi-tenant swift store image sharing doesn't work

[Mark Washenberger]

Using the multi-tenant swift store, I can't read images shared with me.

This seems to be because glance is setting the X-Container-Read header on the image container to be a list of tenant ids. However, a bare tenant id is not among the approved ACL settings, which can only be of the form:

tenant_id:user_id
tenant_name:user_id
*:user_id

Unfortunately there doesn't seem to be any way to really make this work without a change in swift. In particular, we need swift to support something like <tenant_id>:* to indicate that permissions are extended to all users that can successfully authenticate for the given tenant id.

[Byron McCollum (byron-mccollum)]

Swift *does* support this. The proper ACL syntax for all users in an account is just...

<tenant_id>

See: http://docs.openstack.org/developer/swift/misc.html#id5

[Mark Washenberger (markwash)]

Okay, I will double check this bug report, to see what the behavior is now.

[Mark Washenberger (markwash)]

I've been trying to get tenant acl permissions to work in devstack + swift, to no avail. I'm pretty sure this is both a bug in glance and at least a documentation bug in swift. I'll try to walk you through my testing.

First, I've created a container in the demo account, with one object.

ubuntu@devstack:~/devstack$ source accrc/demo/demo
ubuntu@devstack:~/devstack$ swift list
shared
ubuntu@devstack:~/devstack$ swift list shared
hello

Now, I'm going to try to give permission to the alt_demo tenant to list and get this container. But to prove to myself I've got the right tenant id, let's have a look:

ubuntu@devstack:~/devstack$ source accrc/admin/admin
ubuntu@devstack:~/devstack$ keystone tenant-get $alt_demo_tenant_id
+-------------+----------------------------------+
| Property | Value |
+-------------+----------------------------------+
| description | |
| enabled | True |
| id | 35f623050ffd417a9d31165e923710c2 |
| name | alt_demo |
+-------------+----------------------------------+

Also, I saved the alt_demo account token to a local variable, just to prove I don't have anything up that sleeve either:

ubuntu@devstack:~/devstack$ source accrc/alt_demo/alt_demoubuntu@devstack:~/devstack$ swift listalt-demo-private-container
ubuntu@devstack:~/devstack$ curl -i http://10.130.50.54:8080/v1/AUTH_35f623050ffd417a9d31165e923710c2 -H "x-auth-token: $alt_demo_token" && echo
HTTP/1.1 200 OK
Content-Length: 27
Accept-Ranges: bytes
X-Timestamp: 1369164600.76605
X-Account-Bytes-Used: 0
X-Account-Container-Count: 1
Content-Type: text/plain; charset=utf-8
X-Account-Object-Count: 0
X-Trans-Id: tx1d36c4e5e92345e1bfe54-00519bcb70
Date: Tue, 21 May 2013 19:30:56 GMT

alt-demo-private-container

Now, I'll see if I can get the demo shared container using the standard "anyone can read" acl. It works.

ubuntu@devstack:~/devstack$ source accrc/demo/demo
ubuntu@devstack:~/devstack$ swift post -r '.r:*,.rlistings' sharedubuntu@devstack:~/devstack$ curl -i http://10.130.50.54:8080/v1/AUTH_69802d1079724934b4b6228739b270d4/shared -H "x-auth-token: $alt_demo_token" && echo
HTTP/1.1 200 OK
Content-Length: 6
X-Container-Object-Count: 1
Accept-Ranges: bytes
X-Timestamp: 1369163265.54228
X-Container-Bytes-Used: 14
Content-Type: text/plain; charset=utf-8
X-Trans-Id: txbae447f4ca0d4ed99cfb6-00519bcc36
Date: Tue, 21 May 2013 19:34:14 GMT

hello

ubuntu@devstack:~/devstack$ curl -i http://10.130.50.54:8080/v1/AUTH_69802d1079724934b4b6228739b270d4/shared/hello -H "x-auth-token: $alt_demo_token" && echo
HTTP/1.1 200 OK
Content-Length: 14
Content-Type: application/octet-stream
Accept-Ranges: bytes
Last-Modified: Tue, 21 May 2013 19:25:30 GMT
Etag: 8a9c538c7f848d97d9d45736c4f709f3
X-Timestamp: 1369164330.47373
X-Object-Meta-Mtime: 1369164319.763935
X-Trans-Id: tx66a7c40fd40147cd8b1a8-00519bcc3c
Date: Tue, 21 May 2013 19:34:20 GMT

Hello, World.

But if I try to set the acl to just the alt_demo tenant_id, it does not work.

ubuntu@devstack:~/devstack$ swift post -r "$alt_demo_tenant_id" sharedubuntu@devstack:~/devstack$ swift stat shared
  A...

[Mark Washenberger (markwash)]

This is probably just a doc bug or a wishlist item for swift, but I'd like to get feedback from swift folks here. Am I doing something wrong with my swift acls setup in the reports above?

[Kun Huang (academicgareth)]

The related patch is here
https://review.openstack.org/#/c/22820/

[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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/36119