Metacat CN-CN replication permOrder issue with EML-defined access rules
#1 Updated by Ben Leinfelder about 10 years ago
- Category set to Metacat
- Assignee set to Ben Leinfelder
Here's the scenario for sample guid 'knb-lter-sbc.40.2':
- It is an EML 2.1.0 document with embedded access control rules that use the "denyFirst" permOrder are added the a MN instance of Metacat.
- System Metadata for access control does not know about nor care about the permOrder that Metacat uses to record access control.
- CN-unm gets this object from the MN and adds it to it's store - the System Metadata is immediately replicated to the other CNs (CN-ucsb and CN-orc) via the shared Hazelcast System Metadata map and then the EML file is replicated to them via Metacat replication.
- Upon EML replication to these other CNs we already have System Metadata (including access control rules with permOrder=allowFirst) recorded.
- The EML is parsed on the replica CNs and the access control rules embedded in it (permOrder=denyFirst) conflict with those that already exist from the prior System Metadata replication (where permOrder=allowFirst because that was what we chose as the default for System Metadata in Metacat).
- This makes Metacat's xml_access table inconsistent because we end up with a mix of denyFirst and allowFirst for the same guid (in fact this should not even be allowed to be inserted in cases like this, but that's a separate issue).
#2 Updated by Ben Leinfelder about 10 years ago
Now we won't write EML-defined access control rules to the DB during:
- D1 API insert/update
- Metacat replication
This should shield us from polluting the AccessPolicy defined in SystemMetadata when dealing with EML objects.
We also decided to convert all deny/denyFirst access rules to use the allow/allowFirst approach assuming there is no loss of the semantics of the access control block.