RBAC Initialization#

Overview#

Dify's enterprise RBAC system must be explicitly initialized for every App, Dataset, and Agent at the moment of creation. If initialization is skipped, the resource has no access record — non-creator team members hit a 403 when opening it. (The creator is short-circuited by maintainer/owner checks and never sees the error.) The primary tracking issue is #39379 1.

The initialization sequence has three steps 1:

1. replace_whitelist (AppAccess / DatasetAccess / AgentAccess) — seeds the whitelist. automatic_include_workspace_members is True for apps and agents, False for datasets.
2. try_sync_creator_access_policy_member_bindings — wires the creator into any applicable access-policy group 2.
3. initialize_created_app_rbac_access_task (async Celery) — backfills current workspace members into the whitelist. Apps and agents run this task; datasets do not 3.

This sequence is fully wired only into the primary console create controllers. Every other entry point constructs the resource directly and silently omits it 1.

App Creation Coverage#

Console create (AppService.create_app) runs all three initialization steps and dispatches initialize_created_app_rbac_access_task. For agent-mode apps it calls initialize_agent_rbac_access instead of the app-typed path 4.

Agent paths (create, duplicate, .ifpkg import, composer save-to-roster) now all call the shared initialize_agent_rbac_access helper 5. DSL import initializes RBAC for agent apps; non-agent DSL imports still skip it 6.

App package imports (ordinary .ifpkg files, both Workflow and Chatflow, from file upload or URL, including overwrite mode) are routed through AppPackageService.read_package, which validates the archive and extracts bundled inline Agent Skills and configuration files packaged with workflow/chatflow exports. The prepared package is passed to import_app for resource remapping and recreation of node-owned Agents, then delegates to the existing DSL import path. These imports follow the same RBAC initialization behavior as YAML DSL imports: agent packages initialize RBAC, non-agent packages skip it.

Workflow conversion (WorkflowConverter.convert_to_workflow) creates a bare App, commits, fires app_was_created, and returns — no RBAC calls are made 7. This is the remaining gap for app creation.

Dataset Creation Coverage#

As of PR #42430, all dataset creation paths use automatic_include_workspace_members=False. Workspace members must be explicitly granted dataset access; they are no longer automatically included at creation time 8.

Two-Layer Permission Problem#

Datasets have two independent access layers that must stay in sync 8:

1. Legacy enum — Dataset.permission (only_me / all_team_members / partial_members), enforced by check_dataset_permission() on every request.
2. RBAC whitelist — DatasetAccess config in the enterprise RBAC service, gated by RBAC_ENABLED.

When RBAC is enabled, both layers run independently. Mismatches cause 403 errors for correctly-permissioned users. The specific failure mode: a dataset created via file upload defaults to permission=only_me and has no RBAC whitelist — even after assigning "Partial team members" in the RBAC UI, the legacy gate rejects first 1.

check_dataset_permission() has no RBAC_ENABLED branch. PR #41022 added an if not dify_config.RBAC_ENABLED guard to the dataset GET endpoint in datasets.py, but 8 call sites in datasets_document.py remain unguarded 8.

The console empty-dataset create path forces permission=ALL_TEAM to make the legacy gate a pass-through; other create paths do not 1.

Workspace Member Join Path#

When a new member joins a workspace, TenantService.create_tenant_member dispatches sync_joined_workspace_member_rbac_access_task under these conditions 1:

• membership_created=True (not a role update)
• RBAC_ENABLED is true
• Role is not OWNER
• Account is not PENDING

The task iterates all apps, datasets, and agents in the workspace in batches of 500, fetches whitelist configs via ResourceWhitelistConfigs.batch_get, and appends the new member only to resources with automatic_include_workspace_members=True 3.

Impact of the False default for datasets: Since all dataset creation paths now set automatic_include_workspace_members=False, members who join a workspace after dataset creation gain no automatic access to existing datasets 8.

Root Cause, Open Gaps, and Key Files#

Root cause: RBAC-on-create logic is duplicated inline in individual controllers rather than extracted into a shared helper. Any new creation entry point that doesn't copy the boilerplate silently ships with no access records 1.

Agent creation is now partially consolidated under initialize_agent_rbac_access (in api/services/rbac_agent_access_service.py). App and dataset creation paths still inline the logic.

Remaining Gaps#

Key Files#

Related Issues#

• #39379 — Primary tracking issue (partially open)
• #42429 — automatic_include_workspace_members should be False for datasets 9
• #38910 — all_team_members → workspace member sync 10; fixed in PR #39735
• PR #42430 — datasets: set automatic_include_workspace_members=False, fix RAG pipeline DSL import
• PR #39227 — dataset permission ≠ all team → update RBAC config