Bug #2584
MN-MN replicated data files have different acces control rules
100%
History
#1 Updated by Ben Leinfelder about 12 years ago
- Category set to Metacat
- Assignee set to Ben Leinfelder
On the source MN, the data is considered private ("READ not allowed on sbclter.245.1"):
https://mn-stage-ucsb-1.dataone.org/knb/d1/mn/v1/meta/sbclter.245.1
but on the replica it is allowed:
https://mn-stage-ucsb-3.dataone.org/knb/d1/mn/v1/meta/sbclter.245.1\
The CN has it as publically readable as well:
https://cn-stage.dataone.org/cn/v1/meta/sbclter.245.1
#2 Updated by Ben Leinfelder about 12 years ago
After some co-sleuthing with Chris (thanks!) it turns out this is yet-another-EML-induced issue.
The data file, 'sbclter.245.1' has access control rules defined in two different EML files. First it was 'sbclter.244.30' with public access DENIED.
But later it was described by 'knb-sbc-lter.11.2' with public access allowed.
The access table in the DB only has our original deny rule (from sbclter.244.30).
The EML file we processed for this testing batch - 'knb-sbc-lter.11.2' - has public access allowed.
I'm not sure why or how this is allowed on the source MN since the 'knb-sbc-lter.11.2' is the newer document. But it does explain why we are seeing the inconsistent results.
Now, what to do about it is another story
#3 Updated by Ben Leinfelder about 12 years ago
- Status changed from New to Closed
during MN/CN.create() calls, we no longer write EML-defined access control rules into the Metacat store (where they can conflict with those that are already defined as part of the system metadata). So during replicate() we will fetch the EML file to be replicated and only use the associated system metadata to provide the authoritative access policy for the object.
