One-way dbus properties

One-way dbus properties

[Adriana Kobylak]

Wanted to get thoughts on how attempting to clear one-way dbus 
properties should be handled.

There are some properties like Field Mode that are intended to be 
one-way, meaning that you can set them but not clear them:

- 
https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/FieldMode.interface.yaml
       description: >
           Keeps track of whether the BMC is in field mode. Enabling 
field mode
           is intended to be a one-way operation.

If there's a call to clear the property value, currently this is a no-op 
and the REST call returns success but the value is not changed.
Should an error be returned to the user? It's like a read-only property 
but only after it's being set the first time.

Re: One-way dbus properties

[Deepak Kodihalli]

On 24/04/19 8:47 PM, Adriana Kobylak wrote:
> Wanted to get thoughts on how attempting to clear one-way dbus 
> properties should be handled.
> 
> There are some properties like Field Mode that are intended to be 
> one-way, meaning that you can set them but not clear them:
> 
> - 
> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/FieldMode.interface.yaml 
> 
>        description: >
>            Keeps track of whether the BMC is in field mode. Enabling 
> field mode
>            is intended to be a one-way operation.
> 
> If there's a call to clear the property value, currently this is a no-op 
> and the REST call returns success but the value is not changed.
> Should an error be returned to the user?

I think an error (NotAllowed) should be thrown back.

Thanks,
Deepak

Re: One-way dbus properties

[Thomaiyar, Richard Marian]

Adriana,

What's the purpose of this property ? Why we are not using the same in 
RestrictionMode ? Any pointers when RestrictionMode::whitelist / 
blacklist will be used.

Reason: Defining new one, and planning to use Security::RestrictionMode 
itself to indicate that BMC system in not deployed (i.e. not in field), 
or deployed with certain restriction?

Let me know

Regards,

Richard

On 4/24/2019 8:47 PM, Adriana Kobylak wrote:
> Wanted to get thoughts on how attempting to clear one-way dbus 
> properties should be handled.
>
> There are some properties like Field Mode that are intended to be 
> one-way, meaning that you can set them but not clear them:
>
> - 
> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/FieldMode.interface.yaml
>       description: >
>           Keeps track of whether the BMC is in field mode. Enabling 
> field mode
>           is intended to be a one-way operation.
>
> If there's a call to clear the property value, currently this is a 
> no-op and the REST call returns success but the value is not changed.
> Should an error be returned to the user? It's like a read-only 
> property but only after it's being set the first time.
>

Re: One-way dbus properties

[Ratan Gupta]

Hi Adriana,

How is it different from readonly property, so suppose there is a object 
which implements this interface.

when this object gets created, as part of creation we can set the 
property, but after object creation user can,t set

the property.

Am I missing something here?

Ratan

On 24/04/19 8:47 PM, Adriana Kobylak wrote:
> Wanted to get thoughts on how attempting to clear one-way dbus 
> properties should be handled.
>
> There are some properties like Field Mode that are intended to be 
> one-way, meaning that you can set them but not clear them:
>
> - 
> https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/FieldMode.interface.yaml
>       description: >
>           Keeps track of whether the BMC is in field mode. Enabling 
> field mode
>           is intended to be a one-way operation.
>
> If there's a call to clear the property value, currently this is a 
> no-op and the REST call returns success but the value is not changed.
> Should an error be returned to the user? It's like a read-only 
> property but only after it's being set the first time.
>

Re: One-way dbus properties

[Adriana Kobylak]

> 
> What's the purpose of this property ? Why we are not using the same in
> RestrictionMode ? Any pointers when RestrictionMode::whitelist /
> blacklist will be used.
> 
> Reason: Defining new one, and planning to use
> Security::RestrictionMode itself to indicate that BMC system in not
> deployed (i.e. not in field), or deployed with certain restriction?
> 

FieldMode is an 'old' property used in the phosphor-bmc-code-mgmt repo 
to make decisions such as if the code update should fail when there's a 
digital signature mismatch, and whether /usr/local/ is allowed to be 
mounted to allow the system to be patched.
I'd say it's a bit different than the IPMI whitelist in that it doesn't 
necessarily block interfaces, but interfaces use it to make decisions. 
Of course this may be implemented differently in Redfish.
There was just recently a request to return an error when trying to 
clear it since historically it has been a no-op.


> How is it different from readonly property, so suppose there is a
> object which implements this interface.
> 
> when this object gets created, as part of creation we can set the
> property, but after object creation user can,t set
> 
> the property.
> 

The intent is that the property is set by an external entity like 
manufacturing, before a system is shipped, so we don't want to set it 
when the object is created. We want to keep its value unset in the lab 
machines, but if the value is set then it can't be cleared (and per 
Deepak's comment should return an error instead of success).

Re: One-way dbus properties

[Thomaiyar, Richard Marian]

when this value is false (i.e. not in field), then do we need to take 
actions as per RestrictionList or not (i.e. based on the value of 
RestrictionMode).

regards,

Richard

On 5/1/2019 9:02 PM, Adriana Kobylak wrote:
>>
>> What's the purpose of this property ? Why we are not using the same in
>> RestrictionMode ? Any pointers when RestrictionMode::whitelist /
>> blacklist will be used.
>>
>> Reason: Defining new one, and planning to use
>> Security::RestrictionMode itself to indicate that BMC system in not
>> deployed (i.e. not in field), or deployed with certain restriction?
>>
>
> FieldMode is an 'old' property used in the phosphor-bmc-code-mgmt repo 
> to make decisions such as if the code update should fail when there's 
> a digital signature mismatch, and whether /usr/local/ is allowed to be 
> mounted to allow the system to be patched.
> I'd say it's a bit different than the IPMI whitelist in that it 
> doesn't necessarily block interfaces, but interfaces use it to make 
> decisions. Of course this may be implemented differently in Redfish.
> There was just recently a request to return an error when trying to 
> clear it since historically it has been a no-op.
>
>
>> How is it different from readonly property, so suppose there is a
>> object which implements this interface.
>>
>> when this object gets created, as part of creation we can set the
>> property, but after object creation user can,t set
>>
>> the property.
>>
>
> The intent is that the property is set by an external entity like 
> manufacturing, before a system is shipped, so we don't want to set it 
> when the object is created. We want to keep its value unset in the lab 
> machines, but if the value is set then it can't be cleared (and per 
> Deepak's comment should return an error instead of success).
>