I think it would be very helpful to document the S3 policy permissions that are required to use the NIO provider in an ECS or EC2 environment. In particular, it turns out that it's not enough to grant the standard s3:ListBucket, s3:PutObject, s3:GetObject actions. The provider requests ACL information for bucket objects, so we are having to add s3:GetObjectAcl and s3:GetBucketAcl permissions as well, even if all we are doing with the provider is walking the directory tree and enumerating files. This wasn't obvious at all, and required enabling debug logging at the http wire level to see what was going on, and even then it took a sharp-eyed developer to notice the ?acl request in the HTTP GETs.
This may be related to #106... When the NIO client doesn't need to provide Acl info, the NIO provider shouldn't require Acl permissions.
I think it would be very helpful to document the S3 policy permissions that are required to use the NIO provider in an ECS or EC2 environment. In particular, it turns out that it's not enough to grant the standard
s3:ListBucket,s3:PutObject,s3:GetObjectactions. The provider requests ACL information for bucket objects, so we are having to adds3:GetObjectAclands3:GetBucketAclpermissions as well, even if all we are doing with the provider is walking the directory tree and enumerating files. This wasn't obvious at all, and required enabling debug logging at the http wire level to see what was going on, and even then it took a sharp-eyed developer to notice the ?acl request in the HTTP GETs.This may be related to #106... When the NIO client doesn't need to provide Acl info, the NIO provider shouldn't require Acl permissions.