object acl implementation?

[terion-name]

Documentation says:

=List of Amazon S3 Object API's not supported on Minio.
ObjectACL (Use bucket policies instead)

But bucket policies do not cover ObjectACL functionality at all. It is a common task to have public and private files in a single bucket.

Any plans of implementing this functionality, or recommended workarounds?

[harshavardhana]

We will not be implementing Object ACL's @terion-name - bucket policies are the right style to do this with a much more fine grained approach.

Bucket policies can be used to set policies on prefixes not just top level buckets where you can filter the necessary API calls as well say you can have prefixes like these

bucket/2017/outgoing -- can be set to allow calls like GetObject(), HeadObject() (allows only reads)
bucket/2017/incoming -- can be set to allow calls like PutObject() (allows only writes)

This is the most common requirement which is provided by bucket policies, with more control over API calls themselves.

ACLs on the other hand are complex and metadata heavy (which in-turn makes your server unreliable) and as a functionality do not provide nicer set of requirements like bucket policies.

[terion-name]

@harshavardhana prefixes do not cover object acl. If I need to have two files — one private and one public in the same directory (example: user files /user/{id}/files/..., his avatar and his documents scans) - they should be placed in one dir, but with different permissions. And now this is impossible to do

[harshavardhana]

@harshavardhana prefixes do not cover object acl. If I need to have two files — one private and one public in the same directory (example: user files /user/{id}/files/..., his avatar and his documents scans) - they should be placed in one dir, but with different permissions. And now this is impossible to do

You should structure your prefixes properly in that sense, where

/user/{id}/files/public
/user/{id}/files/private

From our end we are not going to implement Object ACLs anytime in near future.

[terion-name]

@harshavardhana hm. and what prefix should be for this case? The {id} is dynamic, obviously. Set a bucket policy for each user?

[harshavardhana]

@harshavardhana hm. and what prefix should be for this case? The {id} is dynamic, obviously. Set a bucket policy for each user?

It would be like this /user/*/files/public/* in your bucket policy, for private you don't need since by default all objects are indeed private. Since the key regex is a flat key match should work properly for all users.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "*"
        ]
      },
      "Resource": [
        "arn:aws:s3:::testbucket/user/*/files/public/*"
      ],
      "Sid": ""
    }
  ]
}

aws s3api --no-verify-ssl put-bucket-policy --bucket testbucket --policy file:///tmp/policy.json

There are two types of key matches are allowed in bucket policies one is * and another is ?

Now if you have this in your Resource

arn:aws:s3:::testbucket/user/*/files/public/*

then the policies will match

arn:aws:s3:::testbucket/user/harsha/files/public/issue

Here the user is harsha

Now if you have this in your Resource

arn:aws:s3:::testbucket/user/?/files/public/*

then the policies will match

arn:aws:s3:::testbucket/user/1/files/public/issue

Here the user is 1 You can even repeat ? to restrict the character length of the users as well. Lets say if you have 6 repeated ?

arn:aws:s3:::testbucket/user/??????/files/public/*

then the policies will match

arn:aws:s3:::testbucket/user/harsha/files/public/issue

[terion-name]

@harshavardhana this is very important information you wrote here, thank you, but it can't be found in docs under policy section. Please, add this to the docs.

[deekoder]

We will improve policy in the new UX.

[challarao]

Is it possible to revisit this? The object ACLs are useful for using Minio as a runtime storage for temporarily allowing different users to upload object(by having a secure random path in the key). Since with pre-signed, multipart gets tricky with SDKs. Having assume role is another option. After thinking around how to implement the use case for a while, I had an epiphany that actually having either object ACL/assume role, makes it possible to implement this use case easily. From users point of view Object ACLs are easier, assume role is more secure to some extent. I'm not sure about the complexity that it adds on Minio implementation though.

[harshavardhana]

Object ACLs are more complex to implement and in AWS S3 it's a legacy way to provide access we will not be implementing ACLs. Instead AssumeRole API is a better alternative.

[qrevel]

What happens if you want to access an object created by an role from a different account?

I got the following situation:

• AWS Account A
  • A S3 bucket (named my-bucket) with a policy allowing test-role of Account B to PutObject
• AWS Account B:
  • A Test IAM Role (named test-role) with the right PutObject on my-bucket.

The default ACL is private. It means objects created by an entity assuming the test-role are not only accessible by it. Even the bucket owner doesn't have access to the object. So how do you make the cross-account access work?

[lock]

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.