Ask Your Question
1

Help with write permission in swift

asked 2014-09-17 01:37:07 -0500

ebyenjoys gravatar image

Hello,

I do have a swift cluster with the tempauth authentication. My tempauth configuration is as below.

[filter:tempauth]
use = egg:swift#tempauth
reseller_prefix = PLAY
user_test_tester = testing .reseller_admin
user_test_eby = testing .admin
user_test_jimmy = testing
user_account_eby = passwd eby .admin
set log_name = tempauth

I am trying to provide the write permission to a user defined in the account called "account" to upload contents to a container called eby which is defined in the test account.

I have posted the write permission to the user account:eby and the permission is listed in the stat as in the image.

image description

Unfortunately,when I try to list or upload the contents with the account:eby to the container eby, it is created as a new container under the account:eby. The uploaded files are also listed as it is under the account:eby.

image description

Kindly help me to sort out this...! Kindly enlight me if iam wrong with the write ACL concept. Thank You..!

edit retag flag offensive close merge delete

2 answers

Sort by ยป oldest newest most voted
0

answered 2014-09-17 21:31:41 -0500

ebyenjoys gravatar image

I have found that,it is only possible for a user under the same account to do the write privilege in to a container defined in that same account and it cannot be done by an user outside that account,even he is assigned the write privilege.

edit flag offensive delete link more
0

answered 2014-09-17 23:56:56 -0500

notmyname gravatar image

Here's what's happening (and it's arguably a bug in swiftclient):

The Swift CLI uses the auth credentials to fetch a token and a storage URL. Then whatever operation you are requesting is applied using that URL and with that token. So when you are using your eby account, you are using a completely separate Swift storage area (ie Swift account) to store the container named "eby".

There is an option in the Swift CLI to override the storage URL. This option is "--os-storage-url". This works great for reading data in other accounts you have permissions in, but the bug is that the swiftclient code does a HEAD request and gets a 403 (unauthorized) to the other account and returns "account not found".

However, Swift itself is behaving properly, and you can use the API directly to do what you want. Here's an example:

On the Swift server:

$ cat /etc/swift/proxy-server.conf
<snip>
[filter:tempauth]
use = egg:swift#tempauth
user_test_tester = testing .admin
user_demo_demo = demo .admin
<snip>

From the client:

john@europa:~$ curl -i -H "X-Auth-Token: AUTH_tk3f3dcdbc765b499f8c4be65072b3759b" http://saio:8080/v1/AUTH_test/
HTTP/1.1 204 No Content
Content-Type: text/plain; charset=utf-8
X-Account-Object-Count: 0
X-Timestamp: 1411014937.17471
X-Account-Bytes-Used: 0
X-Account-Container-Count: 0
X-Put-Timestamp: 1411014937.17471
Content-Length: 0
X-Trans-Id: txee74c891dc1e442e978de-00541a6119
Date: Thu, 18 Sep 2014 04:35:37 GMT

john@europa:~$
john@europa:~$ curl -i -H "X-Auth-Token: AUTH_tk3f3dcdbc765b499f8c4be65072b3759b" http://saio:8080/v1/AUTH_test/c -XPUT -H "X-Container-Write: demo:demo"
HTTP/1.1 201 Created
Content-Length: 0
Content-Type: text/html; charset=UTF-8
X-Trans-Id: txeff57fe14a274884b283d-00541a6141
Date: Thu, 18 Sep 2014 04:36:17 GMT

john@europa:~$
john@europa:~$
john@europa:~$ curl -i -H "X-Auth-Token: AUTH_tk3f3dcdbc765b499f8c4be65072b3759b" http://saio:8080/v1/AUTH_test/c
HTTP/1.1 204 No Content
Content-Length: 0
X-Container-Object-Count: 0
X-Container-Write: demo:demo
Accept-Ranges: bytes
X-Storage-Policy: cupcake
X-Container-Bytes-Used: 0
X-Timestamp: 1411014977.70660
Content-Type: text/html; charset=UTF-8
X-Trans-Id: txc490ae9d3b1746b8adc80-00541a6144
Date: Thu, 18 Sep 2014 04:36:20 GMT

And a different client using the demo account instead of the test account (ie the account delegated write permissions in AUTH_test/c):

john@europa:~$ curl -i -H "X-Auth-User: demo:demo" -H "X-Auth-Key: demo" http://saio:8080/auth/v1.0
HTTP/1.1 200 OK
X-Storage-Url: http://saio:8080/v1/AUTH_demo
X-Auth-Token: AUTH_tka652846fb2c24a1583c98e6d92e2bd70
Content-Type: text/html; charset=UTF-8
X-Storage-Token: AUTH_tka652846fb2c24a1583c98e6d92e2bd70
Content-Length: 0
X-Trans-Id: txe9e0d898ef0a44468766b-00541a615e
Date: Thu, 18 Sep 2014 04:36:46 GMT

john@europa:~$ curl -i -H "X-Auth-Token: AUTH_tka652846fb2c24a1583c98e6d92e2bd70" http://saio:8080/v1/AUTH_demo
HTTP/1.1 204 No Content
Content-Type: text/plain; charset=utf-8
X-Account-Object-Count: 0
X-Timestamp: 1411015021.86855
X-Account-Bytes-Used: 0
X-Account-Container-Count: 0
X-Put-Timestamp: 1411015021.86855
Content-Length: 0
X-Trans-Id: tx1e2df0c1f11944c89ed2e-00541a616d
Date: Thu, 18 Sep 2014 04:37:01 GMT

john@europa:~$ curl -i -H "X-Auth-Token: AUTH_tka652846fb2c24a1583c98e6d92e2bd70" http://saio:8080/v1/AUTH_test/c/o2 --data-binary 1234 -XPUT
HTTP/1.1 201 Created
Last-Modified: Thu, 18 Sep 2014 04:55:45 GMT
Content-Length: 0
Etag: 81dc9bdb52d04dc20036dbd8313ed055
Content-Type: text/html; charset=UTF-8
X-Trans-Id: tx09047f40d1544800aa356-00541a65d0
Date: Thu, 18 Sep 2014 04:55:44 GMT

And now back to the first client (note the use ... (more)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2014-09-17 01:37:07 -0500

Seen: 845 times

Last updated: Sep 17 '14