[
https://issues.apache.org/jira/browse/HDDS-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131575#comment-18131575
]
Siyao Meng commented on HDDS-7552:
----------------------------------
Re-confirmed on apache master at 7212465c0bb19615708c144238317db51c2a696d
during the TLA+ verification work under HDDS-15926 (mini cluster runs, steps
not posted here).
* Still present on current code, and the replication manager in 1.4.0 to 2.2.1
can keep the replica created outside SCM's placement and delete one of the real
replicas of a CLOSED container in its favour. This was seen for a Ratis
container and, separately, for an EC container index, where the real replica of
that index was deleted.
* No key became unreadable in these runs (one real replica was lost per round);
loss of a whole container was not shown.
* A contained datanode side fix does not seem possible without a design
decision: either bind write tokens to the placement (the direction discussed in
HDDS-7454) or give SCM a placement record it can check replica reports against.
The SCM side approach of the closed PR #4477 covers OPEN containers only.
Given the above, I propose raising the priority of this issue and revisiting
the design question.
> Malicious client writing container to another DN can cause dataloss
> -------------------------------------------------------------------
>
> Key: HDDS-7552
> URL: https://issues.apache.org/jira/browse/HDDS-7552
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Sumit Agrawal
> Assignee: Sumit Agrawal
> Priority: Minor
> Labels: pull-request-available
>
> When raw or malicious client write container block to DN for which it is not
> intended can cause data loss.
> Steps:
> # Client is having old pipeline P1 with DN1,DN2,DN3
> # Client get new pipeline from OM, P2 with DN4,DN5,DN6 For Block: Container 5
> # Client write Block to P1 (not intended), which will create Container 5 in
> DN1,DN2,DN3
> # DN1,DN2,DN3 notify SCM for replica of Container 5
> # Currently these replica will be added with transactionId
>
> This malicious addition of replica with mismatching transaction as compared
> to DN4,DN5,DN6 will be in-consistent, and further can cause dataloss, when
> container is closed and replication task handle for over replica/under replica
>
> This case will cause malicious behavior and data loss; and handling is
> required.
> 1) SCM should reject replica addition and based on flag take action of delete
> container or warn log. (Similar to unknown container HDS-3241)
>
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
