Project

General

Profile

Actions

Bug #52455

closed

radosgw-admin user modify, user suspend and user enable cause user-policy of said user to be lost

Added by Pupu Toivonen over 2 years ago. Updated about 1 year ago.

Status:
Duplicate
Priority:
High
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Running any of the user-modifying commands of radosgw-admin against a local radosgw user causes the user-policy of said user to be cleared.
Each of the following commands clears the user-policy, regardless of what the status of the user was and whether anything was actually asked to be changed.

radosgw-admin user modify --uid='tenant$user'
radosgw-admin user suspend --uid='tenant$user'
radosgw-admin user enable --uid='tenant$user'

Tested by setting a user policy over boto3 as an admin user:

iam.put_user_policy(
    UserName="tenant$user",
    PolicyName="STSPolicy", 
    PolicyDocument="{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Deny\",\"Action\":\"s3:*\",\"Resource\":[\"*\"],\"Condition\":{\"BoolIfExists\":{\"sts:authentication\":\"false\"}}},{\"Effect\":\"Allow\",\"Action\":\"sts:GetSessionToken\",\"Resource\":\"*\",\"Condition\":{\"BoolIfExists\":{\"sts:authentication\":\"false\"}}}]}" 
)

And checking for the policy:

iam.get_user_policy(UserName='tenant$user', PolicyName='STSPolicy')

and running any of the aforementioned commands in between checks.
After the commands, a user-policy can be put back again and it will work.

Discovered on v16.2.5 when I re-enabled a previously suspended user and getSessionToken() did not start working again for that user. Root cause so far unknown, not tested on other versions.

Actions #1

Updated by Pupu Toivonen over 2 years ago

I found that user-policy is stored in default.rgw.meta pool in the users.uid namespace as an xattr for the user and seems that for some reason that xattr doesn't survive user modifying functions.

# rados --namespace users.uid -p default.rgw.meta listxattr 'tenant$user'
ceph.objclass.version
user.rgw.user-policy
# radosgw-admin user modify --uid='tenant$user' >/dev/null
# rados --namespace users.uid -p default.rgw.meta listxattr 'tenant$user'
ceph.objclass.version
Actions #2

Updated by Pupu Toivonen over 2 years ago

Actually it seems to throw away anything that might be stored as xattr for the user. Not sure if any other functionality besides user-policy uses xattrs so far, but such functionality would probably be affected as well.

# rados --namespace users.uid -p default.rgw.meta setxattr 'tenant$user' pupu.garbage.attribute "Lettuce!" 
# rados --namespace users.uid -p default.rgw.meta listxattr 'tenant$user'
ceph.objclass.version
pupu.garbage.attribute
user.rgw.user-policy
# radosgw-admin user modify --uid='tenant$user' >/dev/null
# rados --namespace users.uid -p default.rgw.meta listxattr 'tenant$user'
ceph.objclass.version
Actions #3

Updated by Casey Bodley over 2 years ago

  • Status changed from New to In Progress
  • Assignee set to Daniel Gryniewicz
Actions #4

Updated by Daniel Gryniewicz over 2 years ago

  • Assignee deleted (Daniel Gryniewicz)

An update on this issue.

This is not a new issue. I went back to 2013, and it's already there.

The problem is that RGWUser::update() calls store_user() with exclusive false. This eventually (all the way down in RGWSI_SysObj_Core::write()) deletes and re-creates the user, which results in the loss of all attrs. We can't just change RGWUser::update() to call with exclusive true, as other callpaths (like RGWUser::rename()) call update(), and expect the user to be deleted and re-created. This is a non-trivial issue, and will likely require many hours to track down all the codepaths and fix them all, and many (all?) of them will not be covered in test coverage, so chances of breaking something are high.

Actions #5

Updated by Casey Bodley over 2 years ago

  • Priority changed from Normal to High
Actions #6

Updated by Casey Bodley over 2 years ago

  • Assignee set to Daniel Gryniewicz
Actions #7

Updated by Casey Bodley about 1 year ago

  • Status changed from In Progress to Duplicate
Actions

Also available in: Atom PDF