Your examples aren't quite right, meaning you didn't quite understand what
I was saying.
Let's do 3 buckets, created by 3 different users, and the employees Tom and
Bill want access to them...
bucket_a: user_a owner, user_a:tom R, user_a:bill RW
bucket_b: user_b owner, user_b:tom RW, user_b:bill R
bucket_c: user_c owner, user_c:tom R, user_c:bill RW
Bill and Tom can have whichever permissions you want to give them for each
bucket, but they have to have a different access key/secret key pair for
every bucket they have access to. The keys can not be duplicated anywhere
and must be different. I would name bucket_a and user_a the same name for
simplicity so it's obvious which user owns which bucket.
On Tue, Nov 7, 2017, 5:25 AM nigel davies <nigdav...@gmail.com> wrote:
> 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
