Thanks David and All
I am trying out what you said now.
When talking to my manager about permissions, is it possible to set the sub
users with a bucket by bucket permissions, as form your example i would be
granting user_a read only permissions on all buckets and user_b would have
read write permissions on all buckets?
if this is the case and their is no way to set (with out using policy) to do
bucket_a: user_a=R user_b=RW
bucket_b user_a=RW user_b=R
bucket_c user_a=RW user_b=RW
as i think your example would be
bucket_a: user_a=R user_b=RW
bucket_b user_a=R user_b=RW
bucket_c user_a=R user_b=RW
My bad if i am getting all this wrong or confused. it was all going fine
till the permission stuff
On Mon, Nov 6, 2017 at 5:23 PM, David Turner <drakonst...@gmail.com> wrote:
> 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
