[
https://issues.apache.org/jira/browse/HDDS-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630172#comment-17630172
]
Sumit Agrawal commented on HDDS-7454:
-------------------------------------
Thanks [~pifta]
There is a possibility of dataloss in this case, as transaction ID will be
different at different container, and different node will have different
content, So it can cause loss of data as SCM will direct to keep data with
highest transaction ID when container in closed state.
Coming to SCM controlling, SCM just direct the mapping of pipeline and
container but has no control to avoid data write. DN just notify to SCM about
status (on ICR based on state change / FCR), and SCM can either trigger to
close container {+}but can not decline operation{+}. Later SCM close can cause
data loss while close / replication and currently {*}no mechanism to handle
this{*}. If need to add some solution for this, but will be more complicated to
handle afterwards to avoid dataloss (need detect which is correct block, and
what mistake has happened and need perform copy or delete of blocks to avoid
same).
So as security of operation, I think it is required to verify the mapping at DN
using the token of operation and avoid complication if any other solution
required to bring in.
> OM to DN token verification should include Pipeline
> ---------------------------------------------------
>
> Key: HDDS-7454
> URL: https://issues.apache.org/jira/browse/HDDS-7454
> Project: Apache Ozone
> Issue Type: Bug
> Reporter: Sumit Agrawal
> Assignee: Sumit Agrawal
> Priority: Minor
> Labels: pull-request-available
>
> Client will request for block information to be used to write data, In this
> process,
> - OM call allocateBlock to SCM, SCM will provide block information, pipeline
> and related DN
> - OM also create token (when security enabled) with block information
> - Client will pass this information to DN
> - DN will verify token for block information and start write block
> Here, pipeline information is not verified for which request is created. As
> security, this also needs to be verified.
> Pipeline and DN mapping is shared to DN which Pipeline command from SCM to
> DNs, CreatePipelineCommand
> Impact (If client is not trustable):
> 1. Client can forward request with token to different DN with different
> pipeline information.
> So DN since do not have information about SMC mapping of container to
> pipeline, that DN can start operating over that.
> Having pipeline in token verification, it will ensure,
> - block write is done with correct pipeline (DNs)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
