One-way dbus properties
Thomaiyar, Richard Marian
richard.marian.thomaiyar at linux.intel.com
Thu May 2 22:42:15 AEST 2019
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).
>
More information about the openbmc
mailing list