Skip to content
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

mc doesn't work as expected with following IAM policy #2647

Closed
harshavardhana opened this issue Jan 17, 2019 · 1 comment · Fixed by minio/minio-go#1064
Closed

mc doesn't work as expected with following IAM policy #2647

harshavardhana opened this issue Jan 17, 2019 · 1 comment · Fixed by minio/minio-go#1064
Assignees
Milestone

Comments

@harshavardhana
Copy link
Member

yep, this works as expected @WolfspiritM AWS IAM policy returns

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRootAndHomeListingOfCompanyBucket",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::sjm-airlines-1"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        "",
                        "data/",
                        "data"
                    ],
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        }
    ]
}

With AWS S3

~  mc ls testuser/sjm-airlines-1/
mc: <ERROR> Unable to stat `testuser/sjm-airlines-1/`. Access Denied.
~ mc ls testuser/sjm-airlines-1/data/
[2019-01-16 21:31:45 PST]   224B hosts

Using this with Minio has same behavior @WolfspiritM .

Now I started looking at the query params a little deeper, looks like when a top-level bucket is provided mc doesn't send prefix="" (empty) value. This actually causes AWS S3 to not honor the policy.

So after modifying mc query params set prefix="" listing completes properly.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRootAndHomeListingOfCompanyBucket",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::sjm-airlines-1"
            ],
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        "",
                        "data/",
                        "data"
                    ],
                    "s3:delimiter": [
                        "/"
                    ]
                }
            }
        },
        {
            "Sid": "AllowAllActions",
            "Action": [
                "s3:*"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::sjm-airlines-1/data/*"
            ]
        },
        {
            "Sid": "AllowAllBucketActionsRead",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::sjm-airlines-1"
            ]
        }
    ]
}

Here is the final policy which works properly but requires some fixes in mc to pass the appropriate values.

This works with both Minio and AWS IAM. Looks like only fix needed is in mc.

Originally posted by @harshavardhana in minio/minio#7095 (comment)

@harshavardhana harshavardhana transferred this issue from minio/minio Jan 17, 2019
@harshavardhana harshavardhana changed the title mc doesn't work following IAM policy mc doesn't work as expected with following IAM policy Jan 17, 2019
harshavardhana added a commit to harshavardhana/minio-go that referenced this issue Jan 17, 2019
We have never set values which are empty on the request
because they are perhaps not useful in the List query,
but this assumption is wrong when there are restricted
policies for a given user, because empty is actually
a valid value in IAM or Bucket policy conditions.

For example following condition would never work with our
ListObjects call and AWS cli would work fine.
```json
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        "",
                        "data/",
                        "data"
                    ],
                    "s3:delimiter": [
                        "/",
                        ""
                    ]
                }
            }
```

The reason is empty or not `prefix` and `delimiter` should be
added to the query param in List operation, such that server
can use the value to validate the policies for the incoming
request.

Fixes minio/mc#2647
@kannappanr kannappanr added this to the Current milestone Jan 17, 2019
nitisht pushed a commit to minio/minio-go that referenced this issue Jan 20, 2019
We have never set values which are empty on the request
because they are perhaps not useful in the List query,
but this assumption is wrong when there are restricted
policies for a given user, because empty is actually
a valid value in IAM or Bucket policy conditions.

For example following condition would never work with our
ListObjects call and AWS cli would work fine.
```json
            "Condition": {
                "StringEquals": {
                    "s3:prefix": [
                        "",
                        "data/",
                        "data"
                    ],
                    "s3:delimiter": [
                        "/",
                        ""
                    ]
                }
            }
```

The reason is empty or not `prefix` and `delimiter` should be
added to the query param in List operation, such that server
can use the value to validate the policies for the incoming
request.

Fixes minio/mc#2647
@lock
Copy link

lock bot commented Apr 25, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants