<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 8:07 AM, Jeremy Stanley <span dir="ltr"><<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-03-15 13:46:42 +1300 (+1300), Adrian Turjak wrote:<br>
> See, subdomains I can kind of see working, but the problem I have with<br>
> all this in general is that it is kind of silly to try and stop access<br>
> down the tree. If you have a role that lets you do 'admin'-like things<br>
> at a high point in the tree, you inherently always have access to the<br>
> whole tree below you.<br>
</span>[...]<br>
<span class="">> Really if you don't want someone to access or know about<br>
> 'secret_project_d' you make sure 'secret_project_d' is in a totally<br>
> unrelated domain from the people you are trying to hide it from.<br>
<br>
</span>I have to agree on these points; any attempt to build a feature<br>
intended to hide resources from the same groups who delegate the<br>
permission to create them is 1. misguided, and 2. probably entirely<br>
futile. It will ultimately get treated as a feel-good control with<br>
no actual teeth, as well as a hindrance to people who end up working<br>
around it by adding and removing permissions for themselves so they<br>
can see/manage stuff which would otherwise be hidden from them.<br>
<br>
If this makes it in as a supported option, I can't begin to imagine<br>
the embarrassing security holes you'll end up having to squash all<br>
over the place where information about "hidden" resources gets<br>
leaked through side channels in other services (telemetry,<br>
monitoring, basic math on aggregate quotas, et cetera).<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888">--<br>
Jeremy Stanley<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>