Impact: High
Likelihood: Low
According to the discussion with the team, it is expected that in Space
contracts, only one Role can have the Permissions.Owner permission.
Currently, multiple Roles can be created containing this permission.
This is caused by Space.sol’s createRole() function allowing the
OpenZeppelin owner to create new owner-permissioned roles without limit.
Remediations to consider:
Do not allow multiple roles to be created with the ownership permission.
This could be done with something like: if Space.sol’s ownerRoleId is
set, do not allow new roles to be created with the Permissions.Owner
permission.
Fixes HNT-703 as well
Removing the OpenZeppelin ownership logic, and, checking directly for
the ownership of the Space’s SpaceOwner NFT. The SpaceFactory could be
the owner during the bootstrapping phase, and afterwards, could transfer
the NFT to the proper owner. Doing a direct check like
_spaceOwner().ownerOf(tokenId) == _msgSender() would be safe because
that’s what the owner entitlement is going to check eventually.
---------
Co-authored-by: Kerem Kazan <kerem.kazan@gmail.com>
Overloaded isEntitled func in ISpace.sol and Space.sol caused the generated client types to turn into string names. Renaming one of them to isEntitledToChannel.
