Project

General

Profile

Bug #7450

"radosgw-admin key create" ignores specified access key when subuser specified

Added by Robin Johnson about 10 years ago. Updated almost 10 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
% Done:

0%

Source:
Community (user)
Tags:
Backport:
Regression:
No
Severity:
2 - major
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

If I create to create an explicit accesskey/secret key combo, and specify a subuser, then the access key is not used. If the subuser argument is not used, then the keys are correctly created, but not assigned to the subuser.

  1. ceph --version
    ceph version 0.76 (3b990136bfab74249f166dd742fd8e61637e63d9)
  1. radosgw-admin user create --uid=test --display-name=test { "user_id": "test",
    "display_name": "test",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [],
    "keys": [ { "user": "test",
    "access_key": "2D02WGGD48YBH6EXFMX0",
    "secret_key": "tVGZ14wnjwSkw+4N+zqUYxZ+PzpdHaBHEfgQt3OK"}],
    "swift_keys": [],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": { "enabled": false,
    "max_size_kb": -1,
    "max_objects": -1}}
  1. radosgw-admin subuser create --uid=test --subuser=test:test --access=readwrite { "user_id": "test",
    "display_name": "test",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [ { "id": "test:test",
    "permissions": "read-write"}],
    "keys": [ { "user": "test",
    "access_key": "2D02WGGD48YBH6EXFMX0",
    "secret_key": "tVGZ14wnjwSkw+4N+zqUYxZ+PzpdHaBHEfgQt3OK"}],
    "swift_keys": [],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": { "enabled": false,
    "max_size_kb": -1,
    "max_objects": -1}}
  1. radosgw-admin key create --uid=test --subuser=test:test --access-key=D4KJW07WJ33T41S2QDF7 --secret "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP" { "user_id": "test",
    "display_name": "test",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [ { "id": "test:test",
    "permissions": "read-write"}],
    "keys": [ { "user": "test",
    "access_key": "2D02WGGD48YBH6EXFMX0",
    "secret_key": "tVGZ14wnjwSkw+4N+zqUYxZ+PzpdHaBHEfgQt3OK"}, { "user": "test:test",
    "access_key": "MCCQDZRDNXURNK1DB04R",
    "secret_key": "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP"}],
    "swift_keys": [],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": { "enabled": false,
    "max_size_kb": -1,
    "max_objects": -1}}
  1. radosgw-admin key create --uid=test --subuser=test:test --access-key=D4KJW07WJ33T41S2QDF7 --secret "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP" { "user_id": "test",
    "display_name": "test",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [ { "id": "test:test",
    "permissions": "read-write"}],
    "keys": [ { "user": "test",
    "access_key": "2D02WGGD48YBH6EXFMX0",
    "secret_key": "tVGZ14wnjwSkw+4N+zqUYxZ+PzpdHaBHEfgQt3OK"}, { "user": "test:test",
    "access_key": "CXW5RK6EZ5U500FE9HSK",
    "secret_key": "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP"}, { "user": "test:test",
    "access_key": "MCCQDZRDNXURNK1DB04R",
    "secret_key": "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP"}],
    "swift_keys": [],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": { "enabled": false,
    "max_size_kb": -1,
    "max_objects": -1}}
  1. radosgw-admin key create --uid=test --access-key=D4KJW07WJ33T41S2QDF7 --secret "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP" { "user_id": "test",
    "display_name": "test",
    "email": "",
    "suspended": 0,
    "max_buckets": 1000,
    "auid": 0,
    "subusers": [ { "id": "test:test",
    "permissions": "read-write"}],
    "keys": [ { "user": "test",
    "access_key": "2D02WGGD48YBH6EXFMX0",
    "secret_key": "tVGZ14wnjwSkw+4N+zqUYxZ+PzpdHaBHEfgQt3OK"}, { "user": "test:test",
    "access_key": "CXW5RK6EZ5U500FE9HSK",
    "secret_key": "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP"}, { "user": "test",
    "access_key": "D4KJW07WJ33T41S2QDF7",
    "secret_key": "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP"}, { "user": "test:test",
    "access_key": "MCCQDZRDNXURNK1DB04R",
    "secret_key": "QUIdqQM1hVK9lHU6cZFElaUhti0kCTt3iNRTQorP"}],
    "swift_keys": [],
    "caps": [],
    "op_mask": "read, write, delete",
    "default_placement": "",
    "placement_tags": [],
    "bucket_quota": { "enabled": false,
    "max_size_kb": -1,
    "max_objects": -1}}

History

#1 Updated by Robin Johnson about 10 years ago

And this bug exists at least as far back as 0.72. I need a fix/workaround asap, to migrate users+subusers between two Ceph clusters without giving them new keys.

#2 Updated by Ian Colle about 10 years ago

  • Assignee set to Yehuda Sadeh

#3 Updated by Robin Johnson about 10 years ago

The problem is in rgw_user.h:void set_subuser(..) sets 'gen_access = true;'. I can't understand why it's doing that, but I think just dropping it should be safe.

#4 Updated by Yehuda Sadeh about 10 years ago

subusers are only relevant for the swift case, and the regular access-key/secret combination does not apply to them. The way to set swift secret (that applies to a subuser) is to specify --key-type=swift, e.g.:

$ radosgw-admin key create --uid=tester1 --subuser=tester1:tester1 --key-type=swift --secret=foo

#5 Updated by Yehuda Sadeh about 10 years ago

Robin, is that still an issue (considering my previous comment), or should we close this one?

#6 Updated by Robin Johnson about 10 years ago

No, subusers are useful for S3 as well. Maybe this was by accident, but I'm relying on it already in production, for subusers with varying permissions (mostly read, some write).

Create a subuser test:testro, and confirm that you cannot PUT via S3 with it.
Then try to create a specific access+secret for it per my prior instructions, still broken :-(.

#7 Updated by Yehuda Sadeh almost 10 years ago

I pushed some work into wip-7450. It takes care of the default access key generation in the case of subusers, and some other peripheral issues. Does this work for you?

#8 Updated by Robin Johnson almost 10 years ago

@Yehuda: That code change looks good. I'll try to test by monday and get back to you with confirmation of it working.

#9 Updated by Ian Colle almost 10 years ago

  • Status changed from New to Fix Under Review
  • Assignee changed from Yehuda Sadeh to Josh Durgin

Josh please review PR for wip-7450

#10 Updated by Josh Durgin almost 10 years ago

  • Status changed from Fix Under Review to Resolved
  • Assignee changed from Josh Durgin to Yehuda Sadeh

commit:c09f58ef81db9f6dbd528b2aa4c2f135aa6d262e

Also available in: Atom PDF