Please support username acl entries (unique by domain)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Object Storage (swift) |
New
|
Wishlist
|
Unassigned | ||
Bug Description
As the document states the project and user names should not be used as acl entry, because they are not necessary unique. https:/
however domain_name and user_name together is unique with keystone v3 and does not require the users to remember to long uuids, or depend on values `randomized by keystone` .
username@domainname style could be used to distinguish this from the old tenant_
keystone allows to create users with '@' in the name, but if @ in the acl entry it always must be interpreted as user_name + domain_name, and the usernames with '@' are not supported.
Note: keystone does case insensitive name compassion.
BTW: The ':' was also allowed in the usernames.
Please prefer the domain names, not the `randomized` ids.
| Alistair Coles (alistair-coles) wrote | #1 |
| Changed in swift: | |
| importance: | Undecided → Wishlist |
| clayg (clay-gerrard) wrote | #2 |
| summary: |
- Please support username@domain_name acl entries + Please support username acl entries (unique by domain) |
I agree that IDs only in ACLs is unwieldy but when we made that change it was based on advice from the keystone community that names should never be persisted in ACLs. Apart from the challenge of guaranteeing a unique interpretation of names, the binding between names and IDs can, if I understand correctly, also change over time.
If I understand the proposal here, it is that swift keystoneauth would always interpret "bob@domain" as being username "bob" in domain "dom1". That would mean that if a user set an ACL intending to grant permission to a user whose *username* is "bob@dom1" but is, let's say, in the default domain, then keystoneauth would incorrectly grant access to "bob" who is in "dom1". How would we prevent or warn users from using usernames that contain "@"? would that just be documented as a security risk?
I think the closest we have come to a "secure" solution for this inconvenience is to have swift translate user/project/domain names to IDs when ACLs are set, based on a richer ACL syntax that supports user, project and domain names being explicitly specified (e.g. a json format similar to account ACLs). The result being that the ACL stored in swift only uses IDs, but users have a more convenient interface. That is a feature that could be provided by UIs such as horizon rather than being embedded in swift.
Re. "Note: keystone does case insensitive name compassion." - I had understood that to be a property of the particular backend that keystone is using.