Miyabi Access Control

Overview

In Miyabi, access control can be managed at these levels:

• System access control level: Provides a way to manage the access to do operations on Miyabi World State.
• Table access control level: Provides a way to manage the access to user defined tables in Miyabi.

System Access Control Level

System permissions represent the permissions required to manage high-level World State operations. Miyabi core needs a certain set of permissions to manage the World State, such as permission to change the blockchain configuration or permission to create new tables in the World State. Miyabi modules, which extend node functionality, may require their own set of permission hierarchies to manage operations. These system permissions are stored in the system permission table within the World State. These system permissions include the following:

World Permission

Addresses with world permission can make core system level changes to Miyabi. WorldPermission consists of the following level access.

Permission	Behavior
None	Represents no permission
Root	Represents the top level of permission. By default, world admins in the blockchain configuration will be granted the Root permission. An address can only be granted with either the Root permission or some other permission
CreateTable	Represents the permission required to create a new table in Miyabi
ChangeConfig	Represents the permission required for updating system-wide configurations such as updating the blockchain configuration parameters
GrantCreateTable	Represents the permission required to grant the CreateTable permission to other addresses
All	Cumulative of the CreateTable, ChangeConfig, and GrantCreateTable permissions

Module Permission

In Miyabi each module can have its own customized permission hierarchy. The actual access control level management and implementation are left to the module implementation. Modules can register the set of permission levels just like world permission.

An example of one such module permission is used by the Contract module and is defined as ContractPermission to control access to the smart contracts in Miyabi for specific addresses.

Permission	Behavior
None	Represents no permission
Deploy	Represents the permission to deploy a smart contract on Miyabi.
GrantDeploy	Represents the permission to grant and revoke the Deploy contract permission to other addresses. Only addresses with Root world permission can grant/revoke the GrantDeploy contract permission
All	Represents a cumulative of Deploy and GrantDeploy contract permissions

Custom Table Access Control Level

The permissions for the custom tables in Miyabi are primarily determined by the permission model of the table itself. Miyabi features both table-level and row-level permission checks which are orthogonal to each other. The permission model of the custom table is constructed by combining these permission checks, which govern various access control behaviors.

Permission Model

Each custom permissioned table is associated with a PermissionModel which represents the necessary permissions for CRUD operations on table data.

A PermissionModel is defined for each table, combining the table-level and row-level permission checks mentioned above.

PermissionModel	Behavior
PermissionLess	No permission checks will be applied
CheckRowOnly	Only need to pass row-level check
CheckTableOnly	Only need to pass table-level check
TableOrRow	Either table-level check or row-level check should pass
TableAndRow	Both table-level check and row-level check should pass

Table Level Permission

For any PermissionModel, all table-level permissions will be granted to TableOwners who have authority to delete the table and grant permissions to other addresses.

The table-level permission checks on custom permissioned tables are primarily governed by TableAccessControlList. For a given set of credentials, the TableAccessControlList can determine whether permission is granted for a specific operation.

Row Level Permission

The row-level permission checks on custom permissioned tables are done against the row owners of the table. For rows without an owner, permission checks are automatically passed by default.

Note that the Insert permission is table-based. Therefore, if a table has PermissionModel set to CheckRowOnly, any address can create a new row, however, only the row owners, if defined, can update or delete the row.

Custom Table Permission

Custom table permission represents the permission required for the insert, update, and read operations for a custom table. The following are the permissions defined under the custom table permissions.

Permission	Behavior
None	No permission
Insert	Table permission to insert
Update	Table permission to update
Read	Table permission to read
All	Cumulative of Insert, Update, Read permissions

Read Restricted

A boolean ReadRestricted flag is available to control the read permission check for each row. If a table is not read-restricted, no read permission checks will be performed regardless of the chosen PermissionModel. However, if the table is read-restricted, read operations will trigger permission checks based on the PermissionModel of the table.

Table Access Control List

All custom tables in Miyabi are permissioned tables and have a table access control list associated with them. This TableAccessControlList consists of the following members:

Member	Definition
TableOwners	The set of table owner addresses (Only the table owner can grant or revoke permissions for addresses)
Permissions	A key-value pair of addresses and the corresponding CustomTablePermission (Read, Insert, and Update) associated with that address
MultiKeyPermissions	A key-value pair of multisig addresses and the corresponding CustomTablePermission (Read, Insert, and Update) associated with that address
GrantedAddresses	An aggregation of the Permissions and MultiKeyPermissions

Permission Commands

miyabi-cli comes with some built-in commands to update Miyabi related permissions. Details regarding the same have been provided in the core-transaction-subcommands section.