Hi Yehuda, I believe you noticed this issue (http://tracker.ceph.com/issues/12890) as you changed the priority to high. I need your help about the following related questions: 1. When removing a subuser, is it okay to set '--purge-keys' as the default option? If we do so, there is no way to keep the keys since we don't have options like --keep-keys. IMO that is acceptable, but I'm not sure if there exist some scenarios that users want to just delete a subuser but preserve its keys. 2. Do we need to purge both S3 keys and swift keys at the same time? Though ceph documents claim that subuser is designed for swift API, it is allowed to create s3 access-secret key pairs for subusers, and they can be used through s3 interface without any problem. Moreover, when creating a subuser with the command 'radosgw-admin subuser create --uid=test --subuser=test:sub', ceph would by default create an s3 key pair for the subuser. Thus, if we do want to purge keys, I think it is necessary to check both s3 and swift keys and delete all associate entries. 3. Do we need to prevent a subuser without any permission from obtaining the account information? Currently a subuser with permission <none> can get some of the account metadata and its bucket list. The following shows a part of my testing result: sandy@ceph20:~$ curl -i $url -X GET -H "X-Auth-Token: $token" HTTP/1.1 200 OK X-Timestamp: 1442367990.90740 X-Account-Container-Count: 1 X-Account-Object-Count: 2 X-Account-Bytes-Used: 41943040 X-Account-Bytes-Used-Actual: 41943040 X-Trans-Id: ts-default.64171.86-20150916:014630:904 Content-type: text/plain; charset=utf-8 Content-Length: 9 Date: Wed, 16 Sep 2015 01:46:30 GMT bkt_test When doing the tests, I also encountered several other issues that I cannot tell whether are bugs or designed on purpose. i1: As mentioned in question 2, a subuser is created with s3 keys rather than a swift key. i2: The auto-generated s3 secret key is empty, and it is regarded as valid. i3: The account metadata obtained from swift API contains doubled object count and bytes used. For a subuser possessing one container and one object, the results may look like this: sandy@ceph20:~$ curl -i $url -X GET -H "X-Auth-Token: $token2" HTTP/1.1 200 OK X-Timestamp: 1442371316.79489 X-Account-Container-Count: 1 X-Account-Object-Count: 2 X-Account-Bytes-Used: 41943040 X-Account-Bytes-Used-Actual: 41943040 X-Trans-Id: ts-default.64171.99-20150916:024156:790 Content-type: text/plain; charset=utf-8 Content-Length: 9 Date: Wed, 16 Sep 2015 02:41:56 GMT bkt_test sandy@ceph20:~$ curl -i $url/bkt_test -X GET -H "X-Auth-Token: $token2" HTTP/1.1 200 OK X-Timestamp: 1442280690.00000 X-Container-Object-Count: 1 X-Container-Bytes-Used: 20971520 X-Container-Bytes-Used-Actual: 20971520 X-Storage-Policy: default-placement X-Trans-Id: ts-default.64171.100-20150916:024200:482 Content-Length: 9 Accept-Ranges: bytes Content-type: text/plain; charset=utf-8 Date: Wed, 16 Sep 2015 02:42:00 GMT file_test As you can see, the container has only one object of 20M, but the account owns two objects of 40M in total. I checked the .rgw.buckets pool and it contains only one file: sandy@ceph20:~$ rados -p .rgw.buckets ls default.64171.1__shadow_.bSI8b1u0Wff4-2LuEDCYtYkqhpuqPAK_4 default.64171.1__shadow_.bSI8b1u0Wff4-2LuEDCYtYkqhpuqPAK_1 default.64171.1__shadow_.bSI8b1u0Wff4-2LuEDCYtYkqhpuqPAK_5 default.64171.1__shadow_.bSI8b1u0Wff4-2LuEDCYtYkqhpuqPAK_3 default.64171.1_file_test default.64171.1__shadow_.bSI8b1u0Wff4-2LuEDCYtYkqhpuqPAK_2 Your comments and suggestions would be sincerely appreciated, thank you. ----- Best regards, Sangdi ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有杭州华三通信技术有限公司的保密信息，仅限于发送给上面地址中列出 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 邮件！ This e-mail and its attachments contain confidential information from H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
