Actions
Bug #23232
closedRGWCopyObj silently corrupts the object that was mulitpart-uploaded in SSE-C
% Done:
0%
Source:
Tags:
Backport:
luminous
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
rgw
Pull request ID:
Crash signature (v1):
Crash signature (v2):
Description
The issue was found in 12.2.2.
The step to reproduce the issue is that- Create a bucket (Say A-bucket) and upload Object X through multipart upload in SSE-C.
- Create another bucket (Say B-Bucket) but B-Bucket and A-Bucket have different data pools
- Use s3cmd copy X in A-bucket to X_B in B-bucket
- Download X_B from B-bucket and notice that the data is corrupted
- The encrypted data in X_B was in Multipart manner since it is copied from X
- The mannifest in X_B has been changed to Atomic manner by the copy operation
- The GET operation follow the X_B's manifest to to decrypt the data in atomic way while the data is in fact encrypted in multipart way
It seems that current implementation does not support this kind of copy operation.
Before we figure out a comprehensive implementation to make it fully functional (maybe the compression manner instead of relying on the volatile manifest is preferred?), I think we should reject the cross-pool copy operation for multipart SSE-C objects explicitly instead of failing silently. Any suggestion?
Updated by Matt Benjamin about 6 years ago
@jeegn chen, that seems potentially plausible, to me.
Matt
Updated by Jeegn Chen about 6 years ago
Updated by Casey Bodley about 6 years ago
- Related to Bug #23264: Server side encryption support for s3 COPY operation added
Updated by Yuri Weinstein about 6 years ago
Updated by Casey Bodley about 6 years ago
- Status changed from New to Pending Backport
- Backport set to luminous
Updated by Nathan Cutler about 6 years ago
- Copied to Backport #23346: luminous: RGWCopyObj silently corrupts the object that was mulitpart-uploaded in SSE-C added
Updated by Nathan Cutler about 6 years ago
- Status changed from Pending Backport to Resolved
Actions