Directus项目中文件删除权限的设计缺陷分析

在Directus项目的文件服务模块中，存在一个值得注意的权限设计问题。当用户尝试删除文件时，系统不仅要求用户具备删除权限，还额外要求对storage和filename_disk这两个字段拥有读取权限。这种设计在实际应用中可能会带来不必要的权限限制。

问题本质

问题的核心在于文件删除操作的实现逻辑。当前系统在删除文件前会先读取文件的存储位置信息（storage字段）和磁盘文件名（filename_disk字段），然后才执行删除操作。这种实现方式导致了权限要求的连锁反应：即使用户被明确授予了删除权限，但如果缺少这两个字段的读取权限，删除操作仍然会被拒绝。

技术实现分析

在Directus的文件服务(FilesService)中，删除操作的实现流程大致如下：

1. 系统首先查询要删除的文件记录
2. 获取文件的存储位置和磁盘文件名信息
3. 根据这些信息定位并删除实际存储的文件
4. 最后删除数据库中的记录

问题就出在第一步和第二步。系统在验证用户权限时，不仅检查删除权限，还会检查这些字段的读取权限，尽管这些信息最终只用于内部操作，并不需要暴露给用户。

理想解决方案

从技术架构的角度来看，更合理的实现方式应该是：

1. 系统只需验证用户对目标文件的删除权限
2. 内部操作所需的storage和filename_disk信息应该绕过常规的权限检查
3. 这些敏感字段信息只用于服务内部的文件定位和删除操作

这种改进既能保证安全性（用户确实有删除权限），又能避免不必要的权限限制（不需要暴露存储细节给用户）。

影响范围

这个问题会影响以下场景：

• 需要精细控制文件权限的系统
• 希望限制用户查看文件存储细节但允许删除的情况
• 使用自定义权限配置的环境

解决方案建议

对于开发者而言，临时的解决方案是确保删除文件的用户同时拥有相关字段的读取权限。但从长远来看，建议修改FilesService的实现，将内部操作所需的字段查询与用户权限检查分离。

这个问题的修复不仅会提升系统的灵活性，也符合最小权限原则，即用户只需拥有完成操作所必需的最小权限集。