Support subfolder permission overrides with explicit deny rules

[dedetc51]

What type of request is this?

Enhancement of an existing feature

Clear and concise description of the feature you are proposing

Problem

When a user or group is granted access to a parent folder, that access currently applies to every subfolder.

For example, a shared folder named TEST contains five subfolders:

• Allowed
• Finance
• HR
• Legal
• Management

A member should be able to access TEST and TEST/Allowed, while the other four subfolders should remain inaccessible.

Currently, this cannot be configured without reorganizing the folder structure or creating separate shares.

Proposed feature

Add support for inherited subfolder permissions with path-scoped overrides.

For each user or group, an administrator or space manager should be able to configure a folder with one of the following states:

• Inherit permissions from the parent folder
• Allow access
• Deny access

An explicit deny rule should override access inherited from a parent folder.

Example

• TEST: Allowed
  • Allowed: Inherited / Allowed
  • Finance: Denied
  • HR: Denied
  • Legal: Denied
  • Management: Denied

The member should still be able to browse TEST, but should only see and access the authorized subfolder.

Expected behavior

A denied folder and its contents should:

• Not appear in directory listings
• Not be accessible through a direct URL or API request
• Not be downloadable, modified, copied, or moved
• Not appear in search results, recent files, activities, or previews
• Not be accessible through WebDAV
• Not be synchronized by desktop clients

Permission enforcement must happen server-side and not only in the web interface.

Inheritance and precedence

Suggested behavior:

1. Permissions are inherited from the parent folder by default.
2. The most specific matching folder rule takes precedence.
3. An explicit deny takes precedence over an allow at the same level.
4. A denied folder also denies access to its descendants by default.
5. Administrators and space managers retain a recovery mechanism to prevent permanent lockout.

The behavior should also be defined when a user receives conflicting permissions through direct membership and group membership.

User interface suggestion

In the sharing or member-permission dialog, add a section named Subfolder permission exceptions.

This section could display the folder tree and allow an administrator to select:

• Inherit
• Allow
• Deny

Additional considerations

The implementation should account for:

• Direct user permissions versus group permissions
• Folder renaming, moving, copying, and deletion
• Permission-cache invalidation
• Activity logging and auditing
• WebDAV and desktop synchronization
• Search indexing and recent-file results

Using a stable folder identifier instead of only a mutable path could help preserve rules when folders are renamed or moved.

Validations

• Check the feature is not already implemented in the project.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
• Check that the feature is technically feasible and aligns with the project's goals.

[johaven]

Sync-in currently treats spaces as security boundaries, while folders are used to organize content within those boundaries.
In this example, Allowed, Finance, HR, Legal, and Management should be separate spaces, with membership configured independently for each one. Users would then only see the spaces they are authorized to access.

Adding per-user or per-group deny rules on arbitrary subfolders would introduce a second authorization model overlapping with spaces. It would also require permission inheritance and conflict resolution across file browsing, direct API access, search, recent files, WebDAV, synchronization, moves, copies, and caches.

Could you clarify what cannot be achieved with separate spaces or shares, apart from preserving the existing TEST/... folder hierarchy?

If the main requirement is visual grouping, grouping multiple spaces under a common category may be a more appropriate feature than nested folder ACLs.