---
slug: /user-and-permission-overview
---

# User and permission overview

## User

The administrator of seekdb is the `root` user, who can create regular users. User names in seekdb are unique.

## Permission

Permissions are divided into three levels:

  * Global permissions: These are permissions that affect the entire seekdb, such as modifying system settings and accessing all tables.

  * Database permissions: These are permissions that affect all objects in a specific database, such as creating and deleting tables in the corresponding database and accessing tables.

  * Object permissions: These are permissions that affect a specific object, such as accessing a specific table, view, or index.

For more information about permission classification, see [Permission classification](../200.user-and-permission/100.permission-classification.md).

## Permission delegation

Permission delegation solves the problem of centralized authorization. By specifying `with admin/grant option` during authorization, you can grant users the permission to delegate the corresponding permissions to other users. When revoking object permissions, you must also revoke the corresponding permissions that the user has delegated to other users. For example, if A grants B a permission, and B grants C the same permission, when A revokes B's permission, C's permission will also be revoked. However, when revoking system permissions, the delegated permissions are not revoked.

## Role

To facilitate permission management, seekdb provides roles. A role is a combination of system and object permissions, and can also include other roles. You can grant a role to a user, allowing the user to inherit all the permissions within the role.

seekdb does not have any system-defined default roles. For information about role management, see [Role management](340.role-management/100.roles-overview.md).

## Indirect permissions

A user's permissions include both directly granted system and object permissions, as well as permissions obtained through roles. Most operations require either directly granted permissions or indirectly inherited permissions via roles. However, in the following scenarios, direct permissions are required:

* Permissions needed to access objects within a view when creating the view.
* Permissions required to execute statements within a named PL block with definer privileges.

## Permission check

During SQL parsing, all required permissions for an SQL statement are identified and checked against the user's permissions. For system operations, if the user does not have the required permissions, an error is returned. For object access, if the user has no permissions on the object, an error indicating the object does not exist is returned. If the user has other permissions on the object but not the required ones, an error indicating insufficient permissions is returned.