Open Stack

On 3/9/16 8:57 AM, Kiall Mac Innes wrote:
> On 09/03/16 03:48, Andrew Bogott wrote:
>>      Due to the weird public/private hybrid nature of my cloud, I'm
>> frequently needing to abuse policy.conf files in unexpected ways.
>> Today's challenge is the designate policy.  Right now we're running a
>> custom solution that maintains all public dns entries under a single
>> domain:  wmflabs.org.  Here are the current access rules:
>>
>> Members of any project can:
>>
>> 1) Create any subdomains of wmflabs.org
>> 2) Create records under those subdomains
>> 3) Create records under wmflabs.org
> For #3 - The zone won't be visible to users who's auth token doesn't
> belong to the project within which this (DNS) domain exists.. Though, it
> sounds like you found something that works for you? The notion of a
> "shared" domain is something we've talked about, but never settled on a
> good solution.
Right now I'm looking at the code in create_domain() which checks to see 
if a new domain is a sub- or super-domain of an existing domain.  If the 
new domain is (and the sub- or super- belongs to a different project), 
it throws an exception.  In contrast, in create_record it makes a policy 
check, presumably to a similar ends.  I have two thoughts:

1)  Why is it a policy check in one case and a hard-coded prohibition in 
the other?  Presumably if I set a 'create_record: "" ' policy then 
anyone could create any record anywhere; no such option is available 
when it comes to subdomains.

2)  It get me much of the way to my goal if I could just set a 'public' 
flag on a given domain.  Public would not mean that anyone could modify 
the domain, but it would mean that the above checks were skipped, so 
that anyone can create records, subdomains, or superdomains for a public 
domain.

Would patches implementing either or both of the above be welcome? I'm 
not clear on how obscure my use case is.

-Andrew