Bug #38619
closedradosgw-admin user create can be executed repeatedly
0%
Description
Background:
ceph version: 12.2.7 (3ec878d1e53e1aeb47a9f619c49d9e7c0aa384d5) luminous (stable)
Step to reproduce:
radosgw-admin user info --uid="test-user"
{ "user_id": "test-user", "display_name": "test-user", "email": "test-user@a.com", "keys": [ { "user": "test-user", "access_key": "AAAAAAAAAAAAAAAAAAA", "secret_key": "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" } ], }
test-user
already exists, then I can continue to use the create command but nothing seems to happen.radosgw-admin user create --uid=test-user --display-name="test-user"
But if I use the following command, I will receive an error that the user already has, and the exit code of the radosgw-admin
command is 17
radosgw-admin user create --uid=test-user
# could not create user: unable to create user, user: test-user exists
Problem:
Why is there such a difference after the --diplay-name
parameter?
In addition, I think the semantics of the interface design for creating users in the object storage Admin Ops API
are not clear.
Since all users are created, if this user already exists, it should return the error of UserExists
or EmailExists
, instead of adding a key for the user, as it is now.
Updated by Hughen X about 5 years ago
Background:
ceph version: 12.2.7 (3ec878d1e53e1aeb47a9f619c49d9e7c0aa384d5) luminous (stable)¶
Step to reproduce:
radosgw-admin user info --uid="test-user"
{
"user_id": "test-user",
"display_name": "test-user",
"email": "test-user@a.com",
"keys": [
{
"user": "test-user",
"access_key": "AAAAAAAAAAAAAAAAAAA",
"secret_key": "BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
}
],
}
radosgw-admin user info --uid="test-user"
test-user
already exists, then I can continue to use the create command but nothing seems to happen.radosgw-admin user create --uid=test-user --display-name="test-user"
But if I use the following command, I will receive an error that the user already has, and the exit code of the radosgw-admin
command is 17
radosgw-admin user create --uid=test-user
# could not create user: unable to create user, user: test-user exists
Problem:
Why is there such a difference after the --diplay-name
parameter?¶
In addition, I think the semantics of the interface design for creating users in the object storage Admin Ops API
are not clear.
Since all users are created, if this user already exists, it should return the error of UserExists
or EmailExists
, instead of adding a key for the user, as it is now.
Updated by Greg Farnum about 5 years ago
- Project changed from Ceph to rgw
- Category deleted (
librados)
Updated by Abhishek Lekshmanan about 5 years ago
- Tags changed from radosgw-admin user create repeatedly to easy first bug
Updated by Matthew Oliver over 4 years ago
So I've looked into the code. If you supply a display name or an email and the user already exists, execute_modify is called. So will go modify the email or display name on the existing user. This is because display name and email are mutable settings.
So seems this is expected behaviour. However, I'll add message before directing down the 'execute_modify' path to say that the user already exists, modifying existing user, so this is more clear.
Updated by Matthew Oliver over 4 years ago
Actually what I said is wrong. If I try and use a different display-name (or email) then what was already created then we get:
$ radosgw-admin user create --uid=test-user --display-name="test-user2" could not create user: unable to create user, user: test-user exists
So will fix it another way :)
Updated by Matthew Oliver over 4 years ago
Ok, me spamming again. It you can modify, just not the email or the display name. Ie. I can add access and secret keys.
When you add --display-name it checks it with the it's still the same in the existing one and if so, redirects it to the execute_modify. Even if there isn't anything to change.
Question really is, is this modify approach really what we want?
for now I'll raise a patch to add the user exists message, so at least the user is told that before calling execute_modify.
Updated by Matthew Oliver over 4 years ago
I have a PR up here: https://github.com/ceph/ceph/pull/31901
Updated by Casey Bodley over 4 years ago
- Status changed from New to Fix Under Review
- Pull request ID set to 31901
Updated by Casey Bodley over 3 years ago
- Status changed from Fix Under Review to Resolved