[
https://issues.apache.org/jira/browse/HDDS-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630131#comment-17630131
]
István Fajth commented on HDDS-7454:
------------------------------------
This question is not really about security... the main question is whether
Ozone allows to create the same container under two different pipelines, and if
it does how it handles the situation?
If we do not crash with such containers, and if we do not loose data, while we
can read the data wherever it was stored as the metadata is properly saved,
then this is not a problem, as container and block id stored and checked in the
token is defining exactly which block in which container the client is allowed
to write/read, and in this case we probably do not care with the Pipeline much.
If it is a trouble to have the same container id on different sets of
DataNodes, then I think extending the token to verify this on the DataNode side
is a bad idea, as the SCM is the one that issues the Pipeline the container id
and the block id to write to, and after the write it eventually have to get a
confirmation from the client about the finish of the write, and an Incremental
Container Report from the DataNodes about the written container, and block
commit sequence id changes after the block is committed. So SCM has everything
to determine if a write was valid or not, and it is able to decline, and remove
the rogue written data without having to push this onto the DataNode. What do
you think?
> 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]
