Open Stack

On 4/23/19 8:33 AM, Michael McCune wrote:
> On Tue, Apr 23, 2019 at 3:19 AM Slawek Kaplonski <skaplons at redhat.com> wrote:
>> But in some corner case it might be even patched and defaults can be different
>> in some specific cloud.
> 
> after replying to Nate last night, this was the only corner case i
> could think of as well. there /could/ exist a situation  where an
> operator has modified the defaults such that they are not in the
> upstream source, in this case the "default hunting" could be seen as
> an exposure of information. whether that information is useful or not,
> i am still not sure about but it's worth noting. good observation =)

Assuming you have permission to make the API call in the first place, 
wouldn't you be able to determine the defaults based on the results of 
the API call anyway? As in, I create a network and don't pass any value 
for the shared attribute, then I look at the created network and see 
that shared is False by default.

Maybe there are defaults that aren't so easily observable, but in 
general I wouldn't consider them sensitive data. However, I am not a 
security guru so take my opinion for what it's worth.

> 
>> Maybe for such case we can make this new behaviour configurable? So there would
>> be some config option which operator can use to disable accepting default values
>> for forbidden parameters.
> 
> this sounds nice, my concern here would be that it is over-complicated
> for operators but maybe i'm just getting too close to the bike shed ;)
> 
> peace o/
>