-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deleting a marker must not AccessDenied when retention set #690
Comments
IMO the This block:
What is the purpose of the first deletion? Then this block makes no sense:
I think the test wanted to assert the raise of the exception when deleting the specific VersionID, but if so, why calling the exact same call just before the protected Indeed the test is (correctly!) raising an unchecked exception in the expected place:
To me, this test is invalid. |
@jecluis need another pair of eyes to eval what to do here, IMO this should be closed. |
I haven't read the test, but from your description I'm not so sure that's the case. AFAIU, the test is supposed to be deleting a delete marker. That means deleting an object that exists, which introduces a delete marker, and then deleting the latest version id of said object, hence the deleting the delete marker.
It may not be checked, but is used later on. I suspect this is deleting the object, hence creating a delete marker.
It looks to me that it is attempting to delete the delete marker. See how it is deleting the object with a specified version id, which is the same as returned before by the first object deletion. I presume this is the version id of the delete marker that was introduced. Only after that, the test attempts to delete the actual initial object version, and only then expects an Access Denied. To me it seems like what the test expects is to be able to delete the delete marker even under object locking, but expects not being able to delete the actual object version (not the delete marker). I think the only way to assess what is the right thing here is to resort to the documentation and understand whether a delete marker under object locking can be deleted. I suspect it should, although it might require special privileges (like admin, which we should have because we are running these tests with default admin credentials).
As I said above, I don't think that's what the test is trying to do and validate. The operation failing in this case is expected to succeed (i.e., deleting the delete marker), and only the one that comes after (i.e., deleting the object version) is expected to return Access Denied. |
ah yes, I could have completely misunderstood the test; will recheck this, thanks! |
@jecluis the test is correct, we have a bug in the rgw/sfs that makes not properly recognize a deletemarker when handling an object deletion. |
RGWDeleteObj::execute() relies on the return code from rgw::sal::Object::get_obj_state() to ascert the object being deleted is a regular object rather than a delete-marker. The rule is to return -ENOENT to signal a delete-marker. get_obj_state() in rgw/sfs was returning always 0 for any object, therefore also a delete-marker fell into a regular object in RGWDeleteObj::execute(). This is wrong because, when dealing with object lock checks, a delete-marker is always allowed to be deleted regardless of the object's retention mode. Returing 0 was incorrectly preventing a delete-marker to be deleted for object-lock protected objects. Fixes: https://github.com/aquarist-labs/s3gw/issues/690 Signed-off-by: Giuseppe Baccini <[email protected]>
S3 test test_object_lock_delete_object_with_retention_and_marker fails while deleting a previously created delete marker
del_response
is the delete marker created by delete_object without a version id before.Deleting the delete marker should work, but raises a AccessDenied
The text was updated successfully, but these errors were encountered: