It's pretty much identical to creating a user with radosgw-admin except
instead of user create, you do subuser create.  To create subusers for
user_a, you would do something like this...

# read only subuser with the name user_a:read-only
radosgw-admin subuser create --uid=user_a --gen-access-key --gen-secret
--subuser=read-only --key-type=s3 --access=read

The --subuser= is a name you give to the subuser to know what it's for.
The --access= is the type of access that subuser will have to this bucket.
Your options are read, write, readwrite, and full.

For our deployment we create buckets with a user and hand out sub-users to
people to access the bucket.  Usually it's a full access subuser.  We use
the user that created the bucket as an admin user for that bucket and don't
pass out the access and secret keys for it.  This is annoying if a project
needs to access multiple buckets, because they need to have a new key pair
for each bucket.  You also can't set acl permissions for individual objects
in the bucket for a subuser.  The permissions for a key pair will apply to
everything in a bucket.  It works well enough for what we're doing until we
can upgrade to Luminous and take advantage of the newer features for rgw.

On Mon, Nov 6, 2017 at 11:54 AM nigel davies <nigdav...@gmail.com> wrote:

> Thanks all
>
> David if you can explain how to create subusers with keys i happy to try
> and explain to my boss.
>
> The issue i had with the ACLs, for some reason when i upload a file, to
> bucket_a with user_a
>
> user_b cant read the file even tho user_b has read permissions on the
> bucket.
>
> And i tired what Adam said to set the ACLs
>
> s3cmd setacl s3://bucket_name --acl-grant=read:someuser
> s3cmd setacl s3://bucket_name --acl-grant=write:differentuser
>
> but has no luck its like the object is locked to that user only, with what
> ever permissions i set on the bucket it self
>
>
>
> On Mon, Nov 6, 2017 at 4:43 PM, David Turner <drakonst...@gmail.com>
> wrote:
>
>> If you don't mind juggling multiple access/secret keys, you can use
>> subusers.  Just have 1 user per bucket and create subusers with read,
>> write, etc permissions.  The objects are all owned by the 1 user that
>> created the bucket, and then you pass around the subuser keys to the
>> various apps that need that access to the bucket.  It's not pretty, but it
>> works without altering object permissions.
>>
>> On Mon, Nov 6, 2017 at 11:38 AM Adam C. Emerson <aemer...@redhat.com>
>> wrote:
>>
>>> On 06/11/2017, nigel davies wrote:
>>> > ok i am using Jewel vershion
>>> >
>>> > when i try setting permissions using s3cmd or an php script using
>>> s3client
>>> >
>>> > i get the error
>>> >
>>> > <?xml version="1.0"
>>> >
>>> encoding="UTF-8"?><Error><Code>InvalidArgument</Code><BucketName>test_bucket</BucketName><RequestId>
>>> > (truncated...)
>>> >    InvalidArgument (client):  - <?xml version="1.0"
>>> >
>>> encoding="UTF-8"?><Error><Code>InvalidArgument</Code><BucketName>test_bucket</BucketName><RequestId>tx00000000
>>> >
>>> >
>>> 000000000000a-005a005b91-109f-default</RequestId><HostId>109f-default-default</HostId></Error>
>>> >
>>> >
>>> >
>>> > in the log on the s3 server i get
>>> >
>>> > 2017-11-06 12:54:41.987704 7f67a9feb700  0 failed to parse input: {
>>> >     "Version": "2012-10-17",
>>> >     "Statement": [
>>> >         {
>>> >             "Sid": "usr_upload_can_write",
>>> >             "Effect": "Allow",
>>> >             "Principal": {"AWS": ["arn:aws:iam:::user/test"]},
>>> >             "Action": ["s3:ListBucket", "s3:PutObject"],
>>> >             "Resource": ["arn:aws:s3:::test_bucket"]
>>> >         }
>>> > 2017-11-06 12:54:41.988219 7f67a9feb700  1 ====== req done
>>> > req=0x7f67a9fe57e0 op status=-22 http_status=400 ======
>>> >
>>> >
>>> > Any advice on this one
>>>
>>> Well! If you upgrade to Luminous the advice I gave you will work
>>> perfectly. Also Luminous has a bunch of awesome, wonderful new
>>> features like Bluestore in it (and really what other enterprise
>>> storage platform promises to color your data such a lovely hue?)
>>>
>>> But, if you can't, I think something like:
>>>
>>> s3cmd setacl s3://bucket_name --acl_grant=read:someuser
>>> s3cmd setacl s3://bucket_name --acl_grant=write:differentuser
>>>
>>> Should work. Other people than I know a lot more about ACLs.
>>>
>>> --
>>> Senior Software Engineer           Red Hat Storage, Ann Arbor, MI, US
>>> IRC: Aemerson@OFTC, Actinic@Freenode
>>> 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C  7C12 80F7 544B 90ED BFB9
>>> _______________________________________________
>>> ceph-users mailing list
>>> ceph-users@lists.ceph.com
>>> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
>>>
>>
>
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to