On Tue, Sep 15, 2015 at 11:49 PM, Xusangdi <[email protected]> wrote: > I resend this email because I found that somehow the one from ceph-devel > could not be opened normally. Just wanna make sure you received it, thank you. > > > 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.
Yeah, I think it's fine removing its keys if it doesn't exist anymore. > > 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. Yes, both S3 and swift keys for that specific subuser. > > 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 > I'm not sure. The permissions are either read, write, or delete, which don't make sense with regard to this operation. I think we would need to add a new permission type for it to make sense, but I'm not sure this is something we need or want to pursue. > > 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. This is probably a bug. I vaguely remember merging in or reviewing a related fix recently. Are you running the latest? > i2: The auto-generated s3 secret key is empty, and it is regarded as valid. Sounds like a bug. > 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 Sounds like another bug, can you open tickets for the relevant bugs? Thanks, Yehuda > > 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! -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
