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

Failure connecting with IAM user #8034

Closed
cyberduck opened this issue Jun 17, 2014 · 11 comments
Closed

Failure connecting with IAM user #8034

cyberduck opened this issue Jun 17, 2014 · 11 comments
Assignees
Labels
bug fixed s3 AWS S3 Protocol Implementation
Milestone

Comments

@cyberduck
Copy link
Collaborator

cyberduck commented Jun 17, 2014

d42e513 created the issue

I have created an IAM profile for an S3 bucket and connected via Cyberduck on OS X, and all works fine there.

However when I attempt to connect via Cyberduck on Windows 7, I am unsuccessful in various ways with different versions:

  • In version 4.4.5, the software appears to hang upon a connection attempt

  • In version 4.4.4, the software connects but is not able to list the files/directories

  • In version 4.3.1, I am able to connect to the bucket and view the bucket/folder contents. I can retrieve files and delete files. However when I attempt to upload a file to a directory within the bucket where I know I have write permissions, I receive an "Access Denied" message.

I've confirmed that I am using the same credentials in the OS X version as the Windows version to make sure it is not an issue with my IAM policy.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jun 18, 2014

@dkocher commented

Plus attach the file cyberduck.log in the application support directory.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jun 23, 2014

d42e513 commented

The complete cyberduck.log (testing with version 4.3.1 on Windows 7) contains only the following:

2014-06-23 13:47:49,789 [background-7] FATAL ch.cyberduck.core.ProtocolFactory - Unknown protocol with identifier gd

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jun 26, 2014

d42e513 commented

Here is a sample IAM policy to assist with your testing. Cyberduck on OSX works as expected based with this policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1394548390000",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::happy-test-bucket/*",
        "arn:aws:s3:::happy-test-bucket"
      ]
    },
    {
      "Sid": "Stmt1394548390001",
      "Effect": "Allow",
      "Action": [
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::happy-test-bucket/downloads/*"
      ]
    },
    {
      "Sid": "Stmt1394548390002",
      "Effect": "Allow",
      "Action": [
        "s3:DeleteObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::happy-test-bucket/uploads/*"
      ]
    }
  ]
}

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 4, 2014

@dkocher commented

If the cause of the issue is the IAM policy, you should get the same results on both OS X and Windows.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 10, 2014

d42e513 commented

Since OS X works fine and Windows does not, I do not believe that the cause of the issue is the IAM policy. I documented the IAM policy here to assist with debugging.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 15, 2014

@dkocher commented

I have tried to replicate this issue with the same IAM policy and couldn't reproduce any connection failure running the current snapshot build on Windows.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 15, 2014

@dkocher commented

I have found that attempting to upload to a path with no permissions in a bucket that is not in us-east-1 will lead to a broken pipe failure (#7621) instead of the proper access denied failure.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 15, 2014

@dkocher commented

Fail fast with Expect: 100-continue header for PUT requests in e1f5ff8.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 15, 2014

@dkocher commented

The upload with this policy to /uploads/* may also file for large objects if we query for incompleted multipart transfers with a GET request and the uploads request parameter.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 15, 2014

d42e513 commented

I tried the snapshot today, and it worked correctly.

I did need to download the Microsoft Visual C++ 2010 Redistributable Package to get the snapshot to work, as I initially received a "msvcr100.dll is missing" error.

@cyberduck
Copy link
Collaborator Author

cyberduck commented Jul 15, 2014

@dkocher commented

For IAM policies restricting access to certain paths, the blog entry Grant access to user-specific folders in an Amazon S3 bucket is a good read.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug fixed s3 AWS S3 Protocol Implementation
Projects
None yet
Development

No branches or pull requests

2 participants