Project

General

Profile

Actions

Feature #47616

open

Cannot perform server-side copy using STS credentials

Added by Christoph Tonsing over 3 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
% Done:

0%

Source:
Community (user)
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

When having obtained temporary credentials using STS (AssumeRole), I can use these temp credentials to copy files from local machine to ceph and vice versa, but I cannot copy files within a bucket (server-side copy). When attempting the same server-side copy operation using the permanent credentials which were used in calling the AssumeRole command, it succeeds.

The AssumeRolePolicy document of the role is:

{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"arn:aws:iam:::user/129-9bef358e31a44f85b8a84880c459def9\"},\"Action\":\"sts:AssumeRole\"}]}

The permission policy attached to the role is (I've made this as permissive as possible to try to fix the problem without success):

{\"Version\":\"2012-10-17\",\"Statement\":{\"Effect\":\"Allow\",\"Action\":[\"s3:*\"],\"Resource\":\"arn:aws:s3:::*\"}}

The request and response when attempting the server-side copy are shown here:

2020/09/23 16:26:49 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2020/09/23 16:26:49 DEBUG : HTTP REQUEST (req 0xc0006e8200)
2020/09/23 16:26:49 DEBUG : PUT /129-73b1a5466f424d33b39d5b616fb39166/134/18/68copy/home/test/Documents/Testing/rsyncTestingB/test1/loadings/test1.txt HTTP/1.1
Host: redacted
User-Agent: rclone/v1.52.2-232-gff843516-beta
Content-Length: 0
Authorization: XXXX
X-Amz-Acl: private
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Copy-Source: 129-73b1a5466f424d33b39d5b616fb39166/134/18/68/home/test/Documents/Testing/rsyncTestingB/test1/loadings/test1.txt
X-Amz-Date: 20200923T142649Z
X-Amz-Metadata-Directive: COPY
X-Amz-Security-Token: redacted=
Accept-Encoding: gzip
2020/09/23 16:26:49 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

2020/09/23 16:26:49 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2020/09/23 16:26:49 DEBUG : HTTP RESPONSE (req 0xc0006e8200)
2020/09/23 16:26:49 DEBUG : HTTP/2.0 403 Forbidden
Content-Length: 250
Accept-Ranges: bytes
Content-Type: application/xml
Date: Wed, 23 Sep 2020 14:26:49 GMT
X-Amz-Request-Id: tx0000000000000000001de-005f6b5b29-442aa9-default

<Error><Code>AccessDenied</Code><BucketName>129-73b1a5466f424d33b39d5b616fb39166</BucketName><RequestId>tx0000000000000000001de-005f6b5b29-442aa9-default</RequestId><HostId>442aa9-default-default</HostId></Error>
2020/09/23 16:26:49 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In case it helps, as can be seen in the request, I am using rclone for doing the actual transfer.

Actions #1

Updated by Christoph Tonsing over 3 years ago

I accidentally marked this as a feature, but I think it is actually possibly a bug. I can't seem to change the issue type...

Christoph Tonsing wrote:

When having obtained temporary credentials using STS (AssumeRole), I can use these temp credentials to copy files from local machine to ceph and vice versa, but I cannot copy files within a bucket (server-side copy). When attempting the same server-side copy operation using the permanent credentials which were used in calling the AssumeRole command, it succeeds.

The AssumeRolePolicy document of the role is:

[...]

The permission policy attached to the role is (I've made this as permissive as possible to try to fix the problem without success):

[...]

The request and response when attempting the server-side copy are shown here:

2020/09/23 16:26:49 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2020/09/23 16:26:49 DEBUG : HTTP REQUEST (req 0xc0006e8200)
2020/09/23 16:26:49 DEBUG : PUT /129-73b1a5466f424d33b39d5b616fb39166/134/18/68copy/home/test/Documents/Testing/rsyncTestingB/test1/loadings/test1.txt HTTP/1.1
Host: redacted
User-Agent: rclone/v1.52.2-232-gff843516-beta
Content-Length: 0
Authorization: XXXX
X-Amz-Acl: private
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Copy-Source: 129-73b1a5466f424d33b39d5b616fb39166/134/18/68/home/test/Documents/Testing/rsyncTestingB/test1/loadings/test1.txt
X-Amz-Date: 20200923T142649Z
X-Amz-Metadata-Directive: COPY
X-Amz-Security-Token: redacted=
Accept-Encoding: gzip
2020/09/23 16:26:49 DEBUG : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

2020/09/23 16:26:49 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
2020/09/23 16:26:49 DEBUG : HTTP RESPONSE (req 0xc0006e8200)
2020/09/23 16:26:49 DEBUG : HTTP/2.0 403 Forbidden
Content-Length: 250
Accept-Ranges: bytes
Content-Type: application/xml
Date: Wed, 23 Sep 2020 14:26:49 GMT
X-Amz-Request-Id: tx0000000000000000001de-005f6b5b29-442aa9-default

<Error><Code>AccessDenied</Code><BucketName>129-73b1a5466f424d33b39d5b616fb39166</BucketName><RequestId>tx0000000000000000001de-005f6b5b29-442aa9-default</RequestId><HostId>442aa9-default-default</HostId></Error>
2020/09/23 16:26:49 DEBUG : <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In case it helps, as can be seen in the request, I am using rclone for doing the actual transfer.

Actions #2

Updated by Christoph Tonsing over 3 years ago

I am creating another issue of type "bug" for this problem. I unfortunately do not have the rights to delete this issue which I created with the wrong tracker type.

Actions

Also available in: Atom PDF