On Thu, Mar 16, 2017 at 8:07 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2017-03-15 13:46:42 +1300 (+1300), Adrian Turjak wrote: > > See, subdomains I can kind of see working, but the problem I have with > > all this in general is that it is kind of silly to try and stop access > > down the tree. If you have a role that lets you do 'admin'-like things > > at a high point in the tree, you inherently always have access to the > > whole tree below you. > [...] > > Really if you don't want someone to access or know about > > 'secret_project_d' you make sure 'secret_project_d' is in a totally > > unrelated domain from the people you are trying to hide it from. > > I have to agree on these points; any attempt to build a feature > intended to hide resources from the same groups who delegate the > permission to create them is 1. misguided, and 2. probably entirely > futile. It will ultimately get treated as a feel-good control with > no actual teeth, as well as a hindrance to people who end up working > around it by adding and removing permissions for themselves so they > can see/manage stuff which would otherwise be hidden from them. > > If this makes it in as a supported option, I can't begin to imagine > the embarrassing security holes you'll end up having to squash all > over the place where information about "hidden" resources gets > leaked through side channels in other services (telemetry, > monitoring, basic math on aggregate quotas, et cetera). > These security-related corner cases have always come up in the past when we've talked about implementing reseller. Another good example that I struggle with is what happens when you flip the reseller bit for a project admin who goes off and creates their own entities but then wants support? What does the support model look like for the project admin that needs help in a way that maintains data integrity? > -- > Jeremy Stanley > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
