| *** Dslegends has joined #swift3 | 03:02 | |
| *** Dslegends has quit IRC | 03:03 | |
| *** _CrustY has quit IRC | 05:06 | |
| *** _CrustY has joined #swift3 | 05:10 | |
| *** ChadTaljaardt has quit IRC | 05:38 | |
| *** chsc has joined #swift3 | 16:29 | |
| *** xrb has joined #swift3 | 17:53 | |
| xrb | hi all | 17:54 |
|---|---|---|
| xrb | I am trying to define ACLs for a bucket using the S3 interface (setup with Swift, Swift3 and Keystone for the auth) to make it readable to a user from another tenant.. Getting some issues with it.. | 17:56 |
| xrb | The ACLs are visible from S3 (using s3cmd) and I am currently trying to see how they are translated as Swift ACL.. But cannot see any currently.. | 17:58 |
| xrb | Should it work that way? | 17:58 |
| timburke | xrb: are you using the s3_acl option? if so, they won't be translated to swift acls, but rather stored as sysmeta -- there isn't a direct translation between the two. if not, i think we've got some fairly tight constraints on what all we translate to X-Container-* headers: https://github.com/openstack/swift3/blob/master/swift3/acl_utils.py#L30-L43 | 18:07 |
| timburke | the s3_acl code is (for reasons not terribly clear to me) in https://github.com/openstack/swift3/blob/master/swift3/subresource.py -- i think the sysmeta header should be X-Container-Sysmeta-Swift3-Acl | 18:10 |
| xrb | yes, s3_acl is set. I had issues setting acls without this option... | 18:19 |
| xrb | I'll check the doc | 18:19 |
| xrb | what is the best practice re ACLs: to use this option or not? (my focus is to be able to grant bucket access to cross-tenant users) | 18:20 |
| timburke | i'm not sure :-) on the one hand, having it enabled produces better compatibility with S3, allowing things like per-user management and object-level ACLs; on the other, there's no enforcement when going through the Swift API, there's reduced visibility of the settings (as you've noticed), and there are performance penalties for needing to have the object response in hand before making an auth decision | 18:24 |
| timburke | fwiw, i think enabling `force_swift_request_proxy_log` then looking through the proxy logs may shine some light on what's going on | 18:26 |
| timburke | xrb: am i remembering right that you were seeing 404s (as opposed to, say, 403s) when trying to do the cross-tenant request? | 18:26 |
| xrb | will check this option.. | 18:29 |
| xrb | yes, currently I haven't been able to define proper ACL for a cross-tenant user, so that he sees the bucket, he always gets a 404 Bucket Not Found (or similar).. | 18:29 |
| timburke | i'm thinking that the request isn't going to the right swift account... since swift3 doesn't have a global bucket registry, we rely on the auth system to tell us which account to use -- keystone will default to using the account for the user's project, but you can override this by changing the access key id that's used from <access key> to <target account>:<access key> | 18:34 |
| notmyname | timburke: as an aside, it might be interesting to talk about a global bucket registry at the PTG. store a mapping in a dot account a la swauth or something (very likely not an original idea) | 18:35 |
| timburke | notmyname: that is very much how i imagine doing such a thing. i've got two problems: 1) finding time to do it and 2) figuring out what to do about pre-existing containers | 18:44 |
| notmyname | https://assets.listia.com/photos/2361447/original.jpg?s=320x320m&sig=e147e360233071fc&ts=1303259490 <-- /me predicts this will confuse kota_ | 18:47 |
| *** ChadTaljaardt has joined #swift3 | 19:00 | |
| xrb | timburke: is it possible for a user to get access to a cross-tenant bucket without the '<target account>:<access key>' workaround (given proper ACL's on the bucket)? | 19:10 |
| timburke | xrb: not that i'm aware of | 19:12 |
| timburke | does the user need to be able to access buckets in both tenants? | 19:12 |
| xrb | timburke: ideally yes (for what I want to do). Perhaps it's not the proper way to do it.. | 19:13 |
| timburke | the trouble is that we need a way to know which tenant to use for a given request -- if both tenants have a bucket named example-bucket, how do we know which to use? | 19:13 |
| xrb | I see.. | 19:14 |
| xrb | or other possibility: can I define severay users within a tenant, where each user has access to its bucket and not the others? Then I would define an additional user having access to all of them... | 19:14 |
| timburke | xrb: that should be possible... i need to remember how keystone roles interact with ACLs... | 19:17 |
| timburke | out of curiosity, will they only connect through the S3 api, or would some of them need to use the Swift api? i think both should be doable | 19:17 |
| xrb | Probably only through S3.. | 19:21 |
| timburke | should make it a bit simpler. i think you just need to give the tenant-wide user an "admin" role, not give that role to the other users, and have the admin create the buckets with appropriate permissions | 19:28 |
| *** ChadTaljaardt has quit IRC | 19:40 | |
| *** ChadTaljaardt has joined #swift3 | 19:53 | |
| xrb | that would be great | 19:55 |
| xrb | If I have two users u1 and u2 within a tenant, what would be proper permission for a bucket to only be accessible by u1? Would that be through ACL? | 19:57 |
| *** ChadTaljaardt has quit IRC | 21:46 | |
| *** xrb has quit IRC | 22:19 | |
| *** chsc has quit IRC | 23:55 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
