Bug #58725
closedRGW matching guest's stats against bucket owner's when checking quotas
100%
Description
I'm seeing the following behavior on a Pacific (16.2.9) cluster and
wanted to know if it is expected and - eventually - what's the rationale
behind it.
- User A owns the bucket X
- User B is allowed to write to X and also owns other buckets on his own
- Both A and B users have bucket and user quotas set
When User B writes in the bucket X, I can see from the logs that:
- Bucket quota is checked matching User A stats against User A limits
(...so far so - almost - good, being A the owner of the bucket...)
- User quota is checked matching User B stats against User A limits
Recalling that User B stats are affected by his own buckets, I'm
guessing if the last check makes sense.
Updated by Mykola Golub over 1 year ago
I reproduced it with some debug printing added and see that when `RadosBucket::check_quota` [1] is called, the `owner` is set to the user that makes the request, not to the user that owns the bucket. Though the `info.owner` is properly set to the bucket owner. So this simple patch makes it work as expected:
diff --git a/src/rgw/driver/rados/rgw_sal_rados.cc b/src/rgw/driver/rados/rgw_sal_rados.cc index cd0e4e231b6..7ac20b0b19c 100644 --- a/src/rgw/driver/rados/rgw_sal_rados.cc +++ b/src/rgw/driver/rados/rgw_sal_rados.cc @@ -785,7 +785,7 @@ int RadosBucket::check_empty(const DoutPrefixProvider* dpp, optional_yield y) int RadosBucket::check_quota(const DoutPrefixProvider *dpp, RGWQuota& quota, uint64_t obj_size, optional_yield y, bool check_size_only) { - return store->getRados()->check_quota(dpp, owner->get_id(), get_key(), + return store->getRados()->check_quota(dpp, info.owner, get_key(), quota, obj_size, y, check_size_only); }
It leaves the question though if it is expected that the `owner` is set to the user that makes the request. Isn't the bug actually that RadosBucket's `owner` member is wrongly initialized?
Updated by Casey Bodley about 1 year ago
- Status changed from New to In Progress
- Tags set to quota
Updated by Daniel Gryniewicz about 1 year ago
I would expect owner and info.owner to be the same, so something is definitely wrong here. We'd talked about removing the SAL User type entirely, but that's a bigger fix.
Updated by Casey Bodley about 1 year ago
Mykola Golub wrote:
It leaves the question though if it is expected that the `owner` is set to the user that makes the request. Isn't the bug actually that RadosBucket's `owner` member is wrongly initialized?
yes, it definitely is a bug. most/all of the ops initialize rgw::sal::Bucket
with the authorized user s->user
instead of the bucket's actual owner. i think rgw::sal::Bucket
should only expose a rgw_user get_owner() { return info.owner; }
instead of holding a pointer to rgw::sal::User
Updated by Casey Bodley about 1 year ago
- Status changed from In Progress to Fix Under Review
- Assignee changed from Ali Maredia to Casey Bodley
- Backport set to pacific quincy reef
- Pull request ID set to 50925
Updated by Casey Bodley about 1 year ago
- Status changed from Fix Under Review to Pending Backport
Updated by Backport Bot about 1 year ago
- Copied to Backport #59616: pacific: RGW matching guest's stats against bucket owner's when checking quotas added
Updated by Backport Bot about 1 year ago
- Copied to Backport #59617: reef: RGW matching guest's stats against bucket owner's when checking quotas added
Updated by Backport Bot about 1 year ago
- Copied to Backport #59618: quincy: RGW matching guest's stats against bucket owner's when checking quotas added
Updated by Backport Bot about 1 year ago
- Tags changed from quota to quota backport_processed
Updated by Konstantin Shalygin 9 months ago
- Status changed from Pending Backport to Resolved
- % Done changed from 0 to 100