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
S3 ACLs can't be changed in third-party buckets (due to incorrect Owner specification?) #9322
Comments
If you can setup a test bucket with the same ACL configuration that would be great. Let me know if I should provide an IAM user you can reference. |
Absolutely -- I'll provide a bucket and steps to reproduce. Please do provide an IAM user and I'll let you know when the bucket and policy are in place. |
Replying to [comment:2 dkocher]:
The IAM user is
|
I have created bucket
I will run this test again in a moment with debug logging on and supply relevant excerpts. |
Here is the original ACL on
Here is the XML of the ACL Cyberduck tries to set per my test above (extracted from Cyberduck debug log entries):
Note that the Owner has changed to the bucket owner account with ID starting ea4952.... Unless I am mistaken, it is not possible to change the ownership of an S3 object (normally the recommended solution to change actual ownership is for the new owner to copy the object, and then delete the original one). I believe this is causing the error. |
Last update for now. I realized I incorrectly stated the problem in my original description: |
When querying the ACL for the bucket
When trying to read the existing ACL on the file |
Replying to [comment:8 dkocher]: Regardless of this we always defer the owner for the ACL we apply from the bucket and not from any existing owner of the ACL on the file. This is possibly the bug you describe. |
Replying to [comment:8 dkocher]:
This is expected -- I left the ACL on that object as set after upload by the third party IAM user. Because of the bug, that user couldn't change it afterward. Sorry for the confusion; I wasn't intending that you'd be able to change that object's ACL.
I agree that is a reasonable default. However, my proposal for you to reproduce my problem would have been for you to upload another object yourself, say |
Replying to [comment:9 dkocher]:
Yes, this sounds like it. Thanks for the change. I will test as soon as it appears in a snapshot build. |
Replying to [comment:12 bretmartin]:
The latest snapshot builds include this changeset. Can you confirm this is resolved? |
Replying to [comment:13 dkocher]:
I'm still seeing Cyberduck trying to change the owner to the bucket owner (when it should remain the third party account) when trying to modify the ACL as the third party IAM user -- looks the same as my test above. Are the build numbers related to changeset numbers? I note that I have build 19182 but this was fixed in 7b7df1a. Does that mean I have a build not including that changeset? |
Hello/Grüezi,
Thank you for your work on Cyberduck. We have found it useful at my workplace as an S3 transfer client for external collaborators.
When working with a bucket that we own, providing access to a third party using an IAM user in their account, we've found that the third party IAM user is unable to change ACLs on objects in our bucket, yielding this error:
''Cannot change permissions of Creating an AWS IAM user to share data with H3 Biomedicine via Amazon S3.pdf.
Access Denied. Please contact your web hosting service provider for assistance.''
even though their IAM policy and our bucket policy both permit the ACL change. With the same third party IAM credentials, these ACL changes are possible using the AWS CLI.
By turning on Cyberduck debug logging, I found that the ACL change request included the canonical ID of the third party account in the element of the access control policy. However, the owner of the object is our account, not the third party account. I believe this is the reason for the "Access Denied" error from S3 and the difference in behavior from the AWS CLI.
I found this behavior to be the same under 4.6.5, 4.8.2, and 5.0 (19065).
Please let me know if I can provide any additional information or facilitate testing (for example, if you need a third party S3 bucket to test with).
Thanks,
--Bret
The text was updated successfully, but these errors were encountered: