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