Bug #43617
closedRGW check object exists before auth?
0%
Description
We detected a strange behavior or bug - an unauthorized user can check the existence of an object.
Repeats on both mimic and Nautilus (Both frontends is beast).
How to repeat:
1. Checking an existing object with a valid token - we get 200
2. Delete the token - we get 401.
3. Change the name of the object or basket - we get 404.
IMHO for any requests without a token, an error with the code 401 should be returned.
For example:
Checking an existing object with a valid token - we get 200
curl -svi http://test-ceph:7488/swift/v1/AUTH_user/snfiles_83/e27e3368-417d-4a6e-b76a-43207b9532eb -X GET -H "X-Auth-Token: AUTH_rgwtk0c0000006f6e6c696e653a61646d696e7c8fbdcb1329f1a32626de5d3898d71f93efbe59b48da53f0e3ea230ea345153ebf025d0" -o 1
- Trying 10.76.x.y:7488...
- TCP_NODELAY set
- Connected to test-ceph (10.76.x.y) port 7488 (#0)
GET /swift/v1/AUTH_user/snfiles_83/e27e3368-417d-4a6e-b76a-43207b9532eb HTTP/1.1
Host: test-swift:7488
User-Agent: curl/7.67.0
Accept: */*
X-Auth-Token: AUTH_rgwtk0c0000006f6e6c696e653a61646d696e7c8fbdcb1329f1a32626de5d3898d71f93efbe59b48da53f0e3ea230ea345153ebf025d0
- Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 10634296
< Accept-Ranges: bytes
< Last-Modified: Tue, 15 Oct 2019 21:26:33 GMT
< X-Timestamp: 1571174793.54342
< etag: 7162f52df1669ba7f2b75baac989f77a
< X-Object-Meta-Block: True
< X-Trans-Id: tx000000000000000dbdd15-005ddcd507-1b3952-default
< X-Openstack-Request-Id: tx000000000000000dbdd15-005ddcd507-1b3952-default
< Content-Type: binary/octet-stream
< Date: Tue, 26 Nov 2019 07:32:24 GMT
< { [14059 bytes data] - Connection #0 to host test-ceph left intact
Now remove header "X-Auth-token" and get "401".
curl -svi http://test-ceph:7488/swift/v1/AUTH_user/snfiles_83/e27e3368-417d-4a6e-b76a-43207b9532eb -X GET -o 2
- Trying 10.76.x.y:7488...
- TCP_NODELAY set
- Connected to test-ceph (10.76.x.y) port 7488 (#0)
GET /swift/v1/AUTH_user/snfiles_83/e27e3368-417d-4a6e-b76a-43207b9532eb HTTP/1.1
Host: test-ceph:7488
User-Agent: curl/7.67.0
Accept: */*
- Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Content-Length: 12
< X-Trans-Id: tx000000000000000173117-005ddcd532-1b8a3e-default
< X-Openstack-Request-Id: tx000000000000000173117-005ddcd532-1b8a3e-default
< Accept-Ranges: bytes
< Content-Type: text/plain; charset=utf-8
< Date: Tue, 26 Nov 2019 07:33:06 GMT
< { [12 bytes data] - Connection #0 to host test-ceph left intact
Now remove last char in object name (e27e3368-417d-4a6e-b76a-43207b9532eb -> e27e3368-417d-4a6e-b76a-43207b9532e). It object don't exists. And get 404!
curl -svi http://test-ceph:7488/swift/v1/AUTH_user/snfiles_83/e27e3368-417d-4a6e-b76a-43207b9532e -X GET -o 3
- Trying 10.76.x.y:7488...
- TCP_NODELAY set
- Connected to test-ceph (10.76.x.y) port 7488 (#0)
GET /swift/v1/AUTH_user/snfiles_83/e27e3368-417d-4a6e-b76a-43207b9532e HTTP/1.1
Host: test-ceph:7488
User-Agent: curl/7.67.0
Accept: */*
- Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Content-Length: 9
< X-Trans-Id: tx000000000000000026182-005ddcd580-1b8b26-default
< X-Openstack-Request-Id: tx000000000000000026182-005ddcd580-1b8b26-default
< Accept-Ranges: bytes
< Content-Type: text/plain; charset=utf-8
< Date: Tue, 26 Nov 2019 07:34:24 GMT
< { [9 bytes data] - Connection #0 to host test-ceph left intact
Updated by Matthew Oliver about 4 years ago
I've confirmed this is an issue.
And worked my way through the code. And think I see the problem. The swift anon engine is "Auth" the user. When there is an object it will then fail with a 401 as they don't have access to the object. But in the case of a missing object, the user is "authed" and there are no params of the object to check (https://github.com/ceph/ceph/blob/master/src/rgw/rgw_process.cc#L113-L117) so it returns a 404.
I'll have a play and see if I can rework the code to do the right thing. I'll next confirm to see what the s3 side does. Seeing as this seems to happen in the shared area of code.
Stay tuned :)
Updated by Matthew Oliver about 4 years ago
Lol, managed to get it from a 401 for an object and 403 for an object that doesn't exist.. still just as bad as this means you can use it leak object existence out of the cluster, not data, but if an object exists.
But it means there is progress, will continue to dig.
Updated by Matthew Oliver about 4 years ago
OK, have it giving me 401's in both instances now. Now just to work backwards see what minimal change I need to make. Might have hacked a bit to get used to the how this works in ceph :)
Updated by Matthew Oliver about 4 years ago
I have an initial PR: https://github.com/ceph/ceph/pull/33546
Updated by Abhishek Lekshmanan about 4 years ago
- Status changed from New to In Progress
- Pull request ID set to 33546
Updated by Casey Bodley about 4 years ago
- Status changed from In Progress to Fix Under Review
Updated by Casey Bodley about 4 years ago
- Assignee changed from Adam Emerson to Casey Bodley
Updated by Casey Bodley about 4 years ago
- Assignee changed from Casey Bodley to Or Friedmann
Updated by Casey Bodley about 4 years ago
- Status changed from Fix Under Review to Pending Backport
- Backport set to nautilus octopus
Updated by Nathan Cutler almost 4 years ago
- Copied to Backport #45500: octopus: RGW check object exists before auth? added
Updated by Nathan Cutler almost 4 years ago
- Copied to Backport #45501: nautilus: RGW check object exists before auth? added
Updated by Nathan Cutler almost 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".