You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way we are persisting ACLs in ExampleAccessControlDelegate stores the following state:
A TLV struct with a version number (currently 1).
A bunch of entries, with keys that look like "acl/%x" where the %x goes from 0 to CHIP_CONFIG_MAX_FABRICS * CHIP_CONFIG_EXAMPLE_ACCESS_CONTROL_MAX_ENTRIES_PER_FABRIC.
If those config vars change, reading the storage is not going to work right.
Proposed Solution
Depends on whether ExampleAccessControlDelegate is meant for production use. If it is, we need to do something quite different here....
One option here is to have keys of the form "f/%x/acl/c" for the per-fabric counts and "f/%x/acl/%x" for the per-fabric entries and then use the known fabric index list to get things out of storage....
PRs #17357 and #17817 handle most of this, except one spot.
In AclStorage when encoding/decoding from persistent storage (as a flat buffer in KVS), we need an appropriate buffer size. We'd like to put it on the stack. But since it comes from the access control system delegate, we don't know its exact size at compile time.
So minimally that last place needs to be addressed. But also, then we need to go through all the cases (OTA, save new persistent data, revert the OTA, try to load it, etc.) and ensure they all work, before we close this issue.
Problem
The way we are persisting ACLs in ExampleAccessControlDelegate stores the following state:
CHIP_CONFIG_MAX_FABRICS * CHIP_CONFIG_EXAMPLE_ACCESS_CONTROL_MAX_ENTRIES_PER_FABRIC
.If those config vars change, reading the storage is not going to work right.
Proposed Solution
Depends on whether ExampleAccessControlDelegate is meant for production use. If it is, we need to do something quite different here....
One option here is to have keys of the form
"f/%x/acl/c"
for the per-fabric counts and"f/%x/acl/%x"
for the per-fabric entries and then use the known fabric index list to get things out of storage....@mlepage-google @tcarmelveilleux
The text was updated successfully, but these errors were encountered: