1) The glance server paginates list responses (default images listed per response -- limit_param_default -- = 25), so the glance client also paginates image listing.
2) The maximum number of images per page is limited on the server side (default limit -- api_limit_max -- is 1000; this can be reduced by operators)
3) By default, user X cannot add images to user Y's listing [1]
So a user can just add (lots of) database records which won't be seen by other users.
Do we have hard data on how much user X can slow down listing (or other db intensive operations) for user Y?
Eg if we're using mysql, and user X creates 1,000,000 queued images, what is the effect -- in terms of slowdown -- on user Y's listing/other operations?
If a quota is in place a user can still create lots of database records by continuously creating and deleting queued images. Is that considered ok because the operator can purge deleted records?
[1] Marking images as public is admin only by default. The v1 issue of user A spamming user Y with shared images has it's own CVE.
Thanks for raising this Brian.
Some overall observations.
1) The glance server paginates list responses (default images listed per response -- limit_param_default -- = 25), so the glance client also paginates image listing.
2) The maximum number of images per page is limited on the server side (default limit -- api_limit_max -- is 1000; this can be reduced by operators)
3) By default, user X cannot add images to user Y's listing [1]
So a user can just add (lots of) database records which won't be seen by other users.
Do we have hard data on how much user X can slow down listing (or other db intensive operations) for user Y?
Eg if we're using mysql, and user X creates 1,000,000 queued images, what is the effect -- in terms of slowdown -- on user Y's listing/other operations?
Is this a quota issue or a rate limit issue?
For example, would this quota patch be enough to mark as fixed? https:/ /review. openstack. org/#/c/ 244573/
If a quota is in place a user can still create lots of database records by continuously creating and deleting queued images. Is that considered ok because the operator can purge deleted records?
[1] Marking images as public is admin only by default. The v1 issue of user A spamming user Y with shared images has it's own CVE.