Dataset Permission Model#

Dify's dataset access control uses two coexisting layers that must stay in sync 1:

1. Legacy resource-level enum — stored on every Dataset row; always evaluated
2. Enterprise RBAC — gated by the RBAC_ENABLED config flag; only active in enterprise deployments

Legacy Permission Enum#

PermissionEnum (in api/models/enums.py) defines three visibility levels:

DatasetPermissionEnum in api/models/dataset.py is a backward-compatible alias for PermissionEnum; new code should import PermissionEnum from models.enums directly 1.

Legacy Permission Enforcement#

DatasetService.check_dataset_permission() is the primary gate. It:

• Rejects cross-tenant access unconditionally 2
• Bypasses all further checks for the OWNER role 3
• Enforces ONLY_ME by comparing dataset.maintainer to the requesting user 4
• Enforces PARTIAL_TEAM by querying the DatasetPermission table for an explicit record 5

A second variant, check_dataset_operator_permission(), applies the same logic but is used for write/mutation paths.

Critical gap: Neither method contains an RBAC_ENABLED branch. When RBAC is active, these functions are still called and may block access that RBAC would allow — or, conversely, they may pass through access that RBAC should block 1 6.

RBAC-Aware Paths#

The following DatasetService methods do branch on RBAC_ENABLED:

• get_datasets() — filters the dataset list differently depending on RBAC mode. With RBAC enabled and accessible_dataset_ids provided, it restricts to those IDs. Without RBAC, it applies the legacy SQL filter using DatasetPermissionEnum values.
• _can_manage_all_datasets() — checks RBAC_ENABLED first, then calls RBACService.MyPermissions.get() to look for the dataset.create_and_management permission key.

The RBACService.DatasetPermissions.batch_get() and RBACService.MyPermissions.get() methods bridge legacy and RBAC: when RBAC is disabled, they fall back to _LEGACY_MY_PERMISSIONS, which maps tenant roles (OWNER/ADMIN/EDITOR, DATASET_OPERATOR, NORMAL) to dataset.acl.* permission keys 1.

RBAC ↔ Legacy Sync Requirements#

Whenever Dataset.permission changes — or workspace membership changes — the RBAC access policy must be updated. The invariant: 1

• all_team_members → RBAC whitelist must set automatic_include_workspace_members=True and dispatch initialize_created_app_rbac_access_task to grant the default policy to all current members.
• partial_members / only_me → RBAC whitelist must set automatic_include_workspace_members=False.

Mutations that miss this call leave the two layers out of sync, causing access errors even for users who appear correctly permissioned in one layer.

Known Gaps and Fixes#

Specific creation-path RBAC initialization status 6:

Key Files#