There are a couple of problems here. But the core if it is that the CloneTable fate operation uses the target tableName to compute the namespaceId, regardless of whether it should be using the destination namespace or the source namespace. This is an issue because we allow cloning across namespaces (NamespaceIT has an explicit test to verify that this is possible, and that test passes).

First, the check for permissions checks the destination namespace for both the READ permission for the source table and the CREATE permission for the destination namespace, when it should use the source namespace for the former.

Second, the CloneTable fate operation incorrectly uses the destination namespaceId as though it were the source namespaceId, for the purposes of reserving the namespace locks. In both places where the srcNamespaceId and the namespaceId are computed, they use the same tableName (the destination table name) to determine the namespaceId to use.

There may be other related bugs in this code. This ticket just tracks the initial observations.