Bug #5234
closed
Replication -- user does not have permission to update access rule for data file
Added by mike frenock over 13 years ago.
Updated over 12 years ago.
Description
I have a group of files that aren't replicating with the error message that I don't have permission to update access rules for one of the data files. I'm the administrator and both databases (xml_access) show I have all(7) allow permissions on the file via the data-managers group.
<frenockm_> knb 20101029-10:24:30: [ERROR]: ReplicationHandler.handleSingleXMLDocument - Failed to write doc pisco_recruitment.1374.1 into db because User: uid=frenockm,o=PISCO,dc=ecoinformatics,dc=org does not have permission to update access rules for data file pisco_recruitment_UCSC.1 [ReplicationLogging]
<jing> then this is a bug. somebody change the code and the replication rules is broken.
<jing> you may file a bug about this.
Mike:
Can you double check if uid=frenockm,o=PISCO,dc=ecoinformatics,dc=org is the administrator in metacat.properties.
I remember the replication between pisco and knb is single way: PISCO --> KNB. It should NOT have the process to write eml documents and data files to PISCO. Is it another replication?
<frenockm_> I am an administrator in metacat.properties.
<jing> okay.
<frenockm_> the replication is from the UCSB server to OSU server
<frenockm_> the UCSB server also replicates to KNB
<jing> so you are an administrator of OSU.
<frenockm_> yes, and the UCSB PISCO server.
<jing> and the replication is from UCSB to OSU.
<frenockm_> yes
<jing> if this is the case, this is a major bug.
I don't think this has anything to do with the "administrator" defined in the metacat.properties file.
I looked at the xml_access table on KNB and saw that another metadata file was already controlling the permissions for this data file:
http://knb.ecoinformatics.org/knb/metacat/pisco_recruitment_UCSC.18/default
This can't be the first time something like this has come up, but I'm not sure what the approach is when we have two metadata documents attempting to specify access control for the same data file.
Ben:
This happened during the replication. In the replication the access rules should be bypassed. In the early stage, I think we used the user - "null" which had all permissions to all documents and data. I think somebody thinks "null" is not good idea and changed it to the administrator (but i am not 100% sure about this).
Thanks,
Jing
In v1.9.5 we use a null replication user to perform replication (rather than the user_owner from the xml_documents table). When replication is complete for a document, we set the user_owner and user_updated fields with information passed in the document info block.
Original Bugzilla ID was 5234
Also available in: Atom
PDF