When one image member looks up the details of another image member, 404 is returned instead of 403.

[Deepti Ramakrishna]

Suppose project1 and project2 are members of a non-public image. When user1, who belongs to project1, tries to get details of project2, we get 404 Not Found. 403 Forbidden would be more appropriate.

This bug is for the v2 api.

REPRO STEPS:
---------------------
$ export OS_USERNAME=user1
$ export OS_TENANT_NAME=project1
$ openstack token issue // returns 8eb78ce1d12e462fb619b5036dee4086
// project2 id: 6f2aec926def49bebc4c8b71844abc55
// image id: e2846b31-3bb3-4e2f-92da-612804b2ebad
$ curl -g -i -X GET -H 'Content-Type: application/octet-stream' -H 'Accept-Encoding: gzip, deflate, compress' -H 'Accept: */*' -H 'X-Auth-Token: 8eb78ce1d12e462fb619b5036dee4086' http://localhost:9292/v2/images/e2846b31-3bb3-4e2f-92da-612804b2ebad/members/6f2aec926def49bebc4c8b71844abc55

EXPECTED HTTP RESPONSE CODE: 403 Forbidden

ACTUAL HTTP RESPONSE CODE: 404 Not Found

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/178997

[Brian Rosmaita (brian-rosmaita)]

I think that 404 is the correct response here for two reasons.

(1) Information leakage: project1 and project2 are both members of image 123 owned by project0. When project2 makes the request GET /v2/images/123/members/project1, a 403 indicates that project1 is in fact a member of image 123.

(2) When project2 makes the request GET /v2/images/123/members , project2 receives a member-list response (see /v2/schemas/members) containing ONLY the information for project2. So as far as project2 is concerned, there is only one member of image 123. Hence requests for the details of any other projectID should return a 404, since there is no one else in the member-list.

[Erno Kuvaja (jokke)]

Also (mainly because of the reasons Brian pointed out) this seems to be the consistent behavior on similar situations across OpenStack. Stamping as opinion for now.

[Deepti Ramakrishna (dramakri)]

Information leakage is a valid point. However, the current behavior is inconsistent with the following:
- For private images, delete-another-member returns Forbidden.
- For public images (which do not allow any members), all operations except for show() return a blanket 403 Forbidden response.