Details
-
Bug
-
Status: Closed
-
High
-
Resolution: Invalid: Works as Expected
-
v1.4.11
-
None
Description
Hyperledger Fabric 1.4 introduced memberOnlyRead parameter for private data collections. Even if the parameter is set and organization cannot read the private data, it can overwrite or corrupt it.
I have the following configuration:
- Hyperledger Fabric 1.4.11 (tested on 1.4.6 as well, probably all 1.4.x versions affected)
- Solo orderer (for RAFT with chaincode endorsement OR the bug occurs as well; I did not test it with AND endorsement on RAFT)
- Two organizations (org1 and org2).
- One channel and one chaincode (Node.js) for both ogranizations
- Private data collection configuration:
[{
"name": "org1-collection",
"policy": "OR('Org1MSP.member')",
"requiredPeerCount": 1,
"maxPeerCount": 1,
"blockToLive": 0,
"memberOnlyRead": true
}]
Test flow (for OR endorsement policy):
- Start the network, install chaincode
- Put private message by org1 (OK, as expected)
- Get private message by org1 (OK, as expected)
- Verify private message with GetPrivateDataHash by org1 (OK, as expected)
- Verify private message with GetPrivateDataHash by org2 (OK, as expected)
- Get private message by org2 (error, no read access permissions, as expected)
- Put private message by org2 (OK, but IMO should fail. It is possible that this is a feature, because we don't have parameter memberOnlyWrite for 1.4 and you should handle write permissions in chaincode directly. It leads however for further corruption of collection state)
- Get private message by org1 (if the org1 has one peer in the channel, it fails with MVCC_READ_CONFLICT; if the org1 has more peers in the channel, it returns the value put by org2)
Similar situation happens with chaincode with AND(Org1MSP, Org2MSP) endorsement policy. Steps 2-6 behaves as expected. In step 7 the org2 can overwrite the private data. In step 8, however, the org1 is not able to get the private data with error: could not assemble transaction: ProposalResponsePayloads do not match