[
https://issues.apache.org/jira/browse/HDDS-7454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634864#comment-17634864
]
István Fajth commented on HDDS-7454:
------------------------------------
Let me understand this a bit better... As I don't see why the Storage Container
Manager can not decline?
As far as I know, when the container report arrives, if it arrives from a node
on which the block and the container should not present, that the SCM should be
able to know. If it knows, then it can just reject registering what is in the
report about the block (for ICR and FCR also), and then issues a delete block
command to the DN via the next heartbeat, and we got rid of the rouge block and
container from the DataNode side.
Also when the client commits, it should also provide the information about what
was committed, and if the data is written to an unexpected DN, then SCM returns
an error to the client.
I think these checks we anyways should do if having the same container id on
different sets of DataNodes is problematic, as in this case we have to handle
that situation, and we can do the two together as I see now, but I might be
wrong... Why we should check and handle this? Similarly as a rouge client can
put data to the wrong datanode, someone with access to the cluster nodes can
create container directories, or copy containers or partial containers from a
node to an other, and then we face a similar situation if I understand the
problem correctly.
So I still think that the checks on SCM needs to be done anyways, and SCM is
the only one that can check that a container and a block is written to the
expected place and is being reported from the expected place, so still I would
rather not extend the token with the pipeline information just simply as that
is not addressing the real problem when someone circumvents the strict rules of
data placement we have. (It is a good question whether we should delete the
rouge data, or just mark it for operators, as if someone mounts a san volume to
the nodes (with HDFS we have seen such setups), and mix up the mounts we
probably should not delete.)
> 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]
