Bug #64340
openinvalid olh attributes on the target object after copy_object in a versioning suspended bucket
0%
Description
During copy_object in a versioning suspended bucket, the olh attributes (user.rgw.olh.idtag, user.rgw.olh.info, user.rgw.olh.ver) of the source object are copied to the target object, which is causing some problems on the GET request of the target object.
An example problem in our case:
We deleted the source object after the copy, then sent a GET request to get the target object. The Get request crashed the rgw in our ceph version. The ceph main behaves a little bit differently. The GET request didn't crash the rgw, instead, it silently failed. No error code returned, but no content returned either. It looks like the follow_olh follows the wrong/invalid olh.
The steps to reproduce the issue in vstart:
$ aws --endpoint-url http://localhost:8000 s3 ls $ aws --endpoint-url http://localhost:8000 s3 mb s3://bucket1 $ aws --endpoint-url http://localhost:8000 s3api put-bucket-versioning --bucket bucket1 --versioning-configuration Status=Enabled $ aws --endpoint-url http://localhost:8000 s3api get-bucket-versioning --bucket bucket1 $ head -c 4K < /dev/urandom > file_4k $ aws --endpoint-url http://localhost:8000 s3 cp file_4k s3://bucket1/file_4k $ aws --endpoint-url http://localhost:8000 s3api put-bucket-versioning --bucket bucket1 --versioning-configuration Status=Suspended $ aws --endpoint-url http://localhost:8000 s3 cp file_4k s3://bucket1/file_4k $ python3.8 copy_from_other.py <-- a script to copy the object from s3://bucket1/file_4k to s3://bucket1/broom/file_4k $ aws --endpoint-url http://localhost:8000 s3 rm s3://bucket1/file_4k $ aws --endpoint-url http://localhost:8000 s3 cp s3://bucket1/broom/file_4k bbb $ ls -lrt bbb -rw-r--r--. 1 root root 0 Feb 7 05:15 bbb
Proposed fix:
In my opinion, the copy_object shouldn't copy the olh attributes in versioning suspended bucket. I'll put in a PR shortly.