在 HarmonyOS NEXT 的安全体系中应用沙箱隔离是所有文件权限的底层基石而CoreFileKit则是应用操作文件的唯一标准入口。二者共同构建了「内核级隔离 细粒度授权 全生命周期管控」的文件安全框架默认状态下应用间文件完全不可见所有跨应用文件共享必须经过系统统一授权从机制上杜绝了存储权限滥用、路径遍历、数据泄露等经典安全问题。本文从底层沙箱隔离原理出发完整拆解跨应用文件共享的权限流转机制、三种主流共享方式的管控逻辑以及开发侧的最佳实践与避坑指南。一、底层基石强制沙箱隔离机制沙箱不是可选配置而是鸿蒙所有应用的强制运行环境。系统通过内核层的命名空间隔离与挂载点绑定让每个应用拥有独立的文件视图从物理层面切断跨应用直接文件访问的可能。1.1 三级文件访问边界从可见性与权限从高到低系统文件空间分为三层应用默认只能触及最内层空间层级归属访问方式权限要求应用私有沙箱单个应用独占fs直接读写无需权限应用天然拥有完整权限系统公共目录用户所有相册、下载、文档系统选择器获取 URI无需申请权限用户主动选中即授权其他应用沙箱其他应用独占URI 临时授权需属主应用显式授权 系统校验核心红线任何普通应用都无法直接读取另一个应用的沙箱路径。内核会拦截所有跨沙箱路径访问请求即使知道对方的完整文件路径也无法打开这是由挂载命名空间保障的物理隔离。1.2 应用沙箱内部目录结构通过 CoreFileKit 可访问的私有目录全部位于应用沙箱范围内不同目录有不同的生命周期与系统清理规则filesDir持久文件目录应用卸载时删除系统不会自动清理cacheDir缓存目录系统存储空间不足时可能被自动清理distributedFilesDir分布式文件目录用于同账号跨设备文件同步tempDir临时目录应用退出后可能被系统回收所有目录仅当前应用可见、可读写其他应用既看不到路径也无法通过路径访问。1.3 与传统存储权限的本质区别传统移动系统采用「申请存储权限 → 访问整个公共存储」的粗粒度模式应用一旦获得权限即可遍历所有用户文件隐私风险极高。HarmonyOS NEXT 彻底取消了全局公共存储读写权限转向最小必要的文件级授权没有“读整个相册”“读所有文件”的权限应用每次只能访问用户主动选中的单个/多个文件应用无法枚举目录、无法扫描其他文件、无法后台静默访问权限有明确生命周期退出应用后自动失效二、核心机制File URI 临时授权体系沙箱隔离下物理路径完全失去跨应用价值。跨应用文件共享的唯一合法凭证是File URI配合系统统一管理的临时授权机制实现“权限随分享流转用完自动回收”的安全闭环。2.1 File URI跨应用的唯一合法凭证物理路径是沙箱内的本地地址其他应用没有对应挂载点内核会直接拒绝访问。而 File URI 是系统生成的标准化资源标识符本质是「指向文件的能力令牌」而非明文路径。标准格式file://bundleName/沙箱内相对路径核心特性携带属主应用的包名系统可快速校验权限归属不暴露真实物理路径防止路径遍历攻击必须通过fileUri.getUriFromPath()官方接口生成禁止手动拼接字符串只有系统文件服务能将 URI 映射到真实文件应用层无法逆向解析2.2 临时授权的全生命周期管控系统内核维护一张全局授权表记录「调用方应用 → URI → 权限类型 → 有效期」的映射关系所有文件访问必须经过这张表的校验。1. 权限粒度细到单个操作授权不是笼统的“文件访问权”而是按操作维度拆分的细粒度权限对应fileShare.OperationMode枚举READ_MODE只读权限仅可读取文件内容WRITE_MODE写入权限可修改文件内容CREATE_MODE创建权限可在授权目录下新建文件DELETE_MODE删除权限可删除指定文件RENAME_MODE重命名权限分享方可按需授予权限只读场景就不应授予写权限遵循最小必要原则。2. 授权生命周期默认临时可升级持久化授权类型有效期触发方式适用场景临时授权默认接收方应用退出后自动回收Want Flag 授权、选择器授权、系统分享绝大多数单次分享场景持久化授权应用重启、设备重启后依然有效fileShare.persistPermission() 用户确认 受限权限文档编辑器、文件管理器等需要长期访问的场景安全设计持久化授权属于高风险能力需要申请ohos.permission.FILE_ACCESS_PERSIST受限开放权限且必须经过用户明确确认无法静默获取。3. 不可转授原则接收方获得的 URI 权限仅限自身使用不能二次分享给第三方应用也不能转赠权限。如果需要转发必须由原始属主重新授权从根源上避免权限扩散。4. 路径遍历防护系统会对所有 URI 访问做路径规范化校验禁止通过../、符号链接等方式跳出授权范围确保应用只能访问被授权的单个文件无法顺着路径向上遍历访问沙箱其他内容。三、三种主流共享方式的权限管控逻辑CoreFileKit 生态下有三种主流的跨应用文件共享方案分别对应不同业务场景权限管控强度与开发成本各不相同。3.1 系统选择器用户主动授权零权限申请PhotoViewPicker/DocumentViewPicker是最推荐的公共文件访问方式完全由系统托管交互与授权应用无需申请任何存储权限。权限流转过程应用拉起系统选择器自身无法干预界面与文件列表用户手动选中目标文件相当于用户明确同意授权系统向当前应用授予该文件的临时读写权限应用拿到 URI 后即可通过fs.open读写文件内容应用退后台或退出后权限自动失效核心安全特性范围最小化只能访问用户选中的文件看不到目录结构看不到其他文件用户完全可控选不选、选哪个完全由用户决定应用无法绕过零权限成本应用不需要申请任何存储权限降低隐私合规风险3.2 Want 显式授权定向分享给目标应用当应用需要把自己沙箱内的文件传给另一个指定应用如调用 PDF 阅读器打开文档时通过Want携带 URI 权限标志位实现定向授权。标准实现流程属主应用通过fileUri.getUriFromPath()将沙箱路径转为 URI构建Want对象填入 URI、MIME 类型通过flags字段显式授予权限FLAG_AUTH_READ_URI_PERMISSION授予读权限FLAG_AUTH_WRITE_URI_PERMISSION授予写权限调用startAbility拉起目标应用系统校验属主身份合法后向目标应用临时授予对应权限目标应用退出后系统自动回收权限管控要点只能授权自己沙箱内的文件不能把别人的文件再授权出去权限精确到单个文件无法一次性授权整个目录目标应用只能通过 URI 访问无法获取真实物理路径3.3 ShareKit 系统分享标准化全场景分享ShareKit是系统级分享入口在 URI 授权的基础上做了业务层封装同时支持同设备、跨设备分享权限由系统统一调度。权限管控特点配置即授权通过fileShareOptions配置读写权限、有效期系统自动完成权限授予开发者无需手动处理 Flag多形态适配碰一碰、近邻分享、应用内分享所有分享形态复用同一套权限规则跨设备同步授权跨设备分享时分布式软总线传输文件的同时权限同步授予对端应用传输完成后按规则回收高级安全能力支持加密分享、时效分享、水印保护系统级保障文件安全补充共享目录与捐献目录从 API 23 开始系统支持应用配置专属共享目录进一步收敛分享范围防止敏感文件意外泄露应用在module.json5中配置share_files目录只有该目录下的文件可被分享出去API 26 新增捐献目录可向系统文件管理器开放用户可通过系统文件管理器访问该目录本质是在沙箱内部再划一道安全边界将“可分享数据”与“内部敏感数据”物理隔离四、底层安全设计的五大原则整个沙箱与权限体系的设计始终遵循五条核心安全原则从架构层面保障数据主权默认零信任应用之间默认完全不可见、不可访问任何跨应用交互都必须经过显式授权最小必要只授予完成业务必需的最小权限范围、最短有效时长、最少操作权限用户主权所有文件级授权必须有用户明确的交互确认点击选择、点击分享禁止后台静默授权权限不可转授接收方只能自己使用权限不能二次分发避免权限无限扩散生命周期自动回收临时权限随应用生命周期自动失效避免永久遗留的权限泄露风险五、开发最佳实践与避坑指南5.1 最佳实践优先使用系统选择器公共文件访问优先用 Picker无需申请权限合规风险最低用户体验也最统一。永远用 URI 传递文件所有跨应用、跨进程文件传递一律使用 File URI绝对不要传递物理路径字符串。按需授予权限只读场景绝不授予写权限临时够用就绝不申请持久化授权权限范围越小越安全。共享目录收敛数据把可对外分享的文件统一放到共享目录中避免内部配置、日志、缓存等敏感文件被意外分享。敏感文件不跨应用分享Token、密钥、用户隐私数据尽量留在应用内部处理不要通过文件方式跨应用传递。5.2 常见踩坑直接传沙箱路径对方打开失败沙箱路径仅当前应用有效跨应用必须通过fileUri.getUriFromPath转为标准 URI否则必然触发权限拒绝。保存 URI 下次使用失效选择器、单次分享获得的都是临时授权应用退出后权限自动回收。需要长期访问必须走persistPermission持久化授权流程且需用户确认。试图路径遍历突破沙箱系统内核层会做路径规范化校验../、符号链接都无法突破沙箱边界属于无效操作。选择器拿到的 URI 无法二次分享从 Picker 获取的 URI 只有当前应用的临时访问权不具备再授权能力。要分享给第三方需要先持久化授权或将文件拷贝到自身沙箱后再分享。授权整个目录URI 授权默认仅支持单个文件目录级授权需要使用目录选择器并配合持久化权限不能通过单文件 URI 推导目录权限。总结CoreFileKit 配合沙箱隔离与 URI 临时授权本质上是将文件共享的控制权从应用收归到系统和用户手中应用不再能拿到全局存储权限只能在用户明确授权的范围内、限定的时间内访问指定的文件。这套机制虽然在开发上增加了一定的规范约束但从架构层面解决了长期困扰移动生态的存储权限滥用问题既保障了用户隐私安全也通过标准化的接口降低了合规开发成本。理解这套权限管控逻辑不仅能避免绝大多数文件访问的异常报错也能让应用的隐私合规设计更合理。
在 HarmonyOS NEXT 的安全体系中应用沙箱隔离是所有文件权限的底层基石而CoreFileKit则是应用操作文件的唯一标准入口。二者共同构建了「内核级隔离 细粒度授权 全生命周期管控」的文件安全框架默认状态下应用间文件完全不可见所有跨应用文件共享必须经过系统统一授权从机制上杜绝了存储权限滥用、路径遍历、数据泄露等经典安全问题。本文从底层沙箱隔离原理出发完整拆解跨应用文件共享的权限流转机制、三种主流共享方式的管控逻辑以及开发侧的最佳实践与避坑指南。一、底层基石强制沙箱隔离机制沙箱不是可选配置而是鸿蒙所有应用的强制运行环境。系统通过内核层的命名空间隔离与挂载点绑定让每个应用拥有独立的文件视图从物理层面切断跨应用直接文件访问的可能。1.1 三级文件访问边界从可见性与权限从高到低系统文件空间分为三层应用默认只能触及最内层空间层级归属访问方式权限要求应用私有沙箱单个应用独占fs直接读写无需权限应用天然拥有完整权限系统公共目录用户所有相册、下载、文档系统选择器获取 URI无需申请权限用户主动选中即授权其他应用沙箱其他应用独占URI 临时授权需属主应用显式授权 系统校验核心红线任何普通应用都无法直接读取另一个应用的沙箱路径。内核会拦截所有跨沙箱路径访问请求即使知道对方的完整文件路径也无法打开这是由挂载命名空间保障的物理隔离。1.2 应用沙箱内部目录结构通过 CoreFileKit 可访问的私有目录全部位于应用沙箱范围内不同目录有不同的生命周期与系统清理规则filesDir持久文件目录应用卸载时删除系统不会自动清理cacheDir缓存目录系统存储空间不足时可能被自动清理distributedFilesDir分布式文件目录用于同账号跨设备文件同步tempDir临时目录应用退出后可能被系统回收所有目录仅当前应用可见、可读写其他应用既看不到路径也无法通过路径访问。1.3 与传统存储权限的本质区别传统移动系统采用「申请存储权限 → 访问整个公共存储」的粗粒度模式应用一旦获得权限即可遍历所有用户文件隐私风险极高。HarmonyOS NEXT 彻底取消了全局公共存储读写权限转向最小必要的文件级授权没有“读整个相册”“读所有文件”的权限应用每次只能访问用户主动选中的单个/多个文件应用无法枚举目录、无法扫描其他文件、无法后台静默访问权限有明确生命周期退出应用后自动失效二、核心机制File URI 临时授权体系沙箱隔离下物理路径完全失去跨应用价值。跨应用文件共享的唯一合法凭证是File URI配合系统统一管理的临时授权机制实现“权限随分享流转用完自动回收”的安全闭环。2.1 File URI跨应用的唯一合法凭证物理路径是沙箱内的本地地址其他应用没有对应挂载点内核会直接拒绝访问。而 File URI 是系统生成的标准化资源标识符本质是「指向文件的能力令牌」而非明文路径。标准格式file://bundleName/沙箱内相对路径核心特性携带属主应用的包名系统可快速校验权限归属不暴露真实物理路径防止路径遍历攻击必须通过fileUri.getUriFromPath()官方接口生成禁止手动拼接字符串只有系统文件服务能将 URI 映射到真实文件应用层无法逆向解析2.2 临时授权的全生命周期管控系统内核维护一张全局授权表记录「调用方应用 → URI → 权限类型 → 有效期」的映射关系所有文件访问必须经过这张表的校验。1. 权限粒度细到单个操作授权不是笼统的“文件访问权”而是按操作维度拆分的细粒度权限对应fileShare.OperationMode枚举READ_MODE只读权限仅可读取文件内容WRITE_MODE写入权限可修改文件内容CREATE_MODE创建权限可在授权目录下新建文件DELETE_MODE删除权限可删除指定文件RENAME_MODE重命名权限分享方可按需授予权限只读场景就不应授予写权限遵循最小必要原则。2. 授权生命周期默认临时可升级持久化授权类型有效期触发方式适用场景临时授权默认接收方应用退出后自动回收Want Flag 授权、选择器授权、系统分享绝大多数单次分享场景持久化授权应用重启、设备重启后依然有效fileShare.persistPermission() 用户确认 受限权限文档编辑器、文件管理器等需要长期访问的场景安全设计持久化授权属于高风险能力需要申请ohos.permission.FILE_ACCESS_PERSIST受限开放权限且必须经过用户明确确认无法静默获取。3. 不可转授原则接收方获得的 URI 权限仅限自身使用不能二次分享给第三方应用也不能转赠权限。如果需要转发必须由原始属主重新授权从根源上避免权限扩散。4. 路径遍历防护系统会对所有 URI 访问做路径规范化校验禁止通过../、符号链接等方式跳出授权范围确保应用只能访问被授权的单个文件无法顺着路径向上遍历访问沙箱其他内容。三、三种主流共享方式的权限管控逻辑CoreFileKit 生态下有三种主流的跨应用文件共享方案分别对应不同业务场景权限管控强度与开发成本各不相同。3.1 系统选择器用户主动授权零权限申请PhotoViewPicker/DocumentViewPicker是最推荐的公共文件访问方式完全由系统托管交互与授权应用无需申请任何存储权限。权限流转过程应用拉起系统选择器自身无法干预界面与文件列表用户手动选中目标文件相当于用户明确同意授权系统向当前应用授予该文件的临时读写权限应用拿到 URI 后即可通过fs.open读写文件内容应用退后台或退出后权限自动失效核心安全特性范围最小化只能访问用户选中的文件看不到目录结构看不到其他文件用户完全可控选不选、选哪个完全由用户决定应用无法绕过零权限成本应用不需要申请任何存储权限降低隐私合规风险3.2 Want 显式授权定向分享给目标应用当应用需要把自己沙箱内的文件传给另一个指定应用如调用 PDF 阅读器打开文档时通过Want携带 URI 权限标志位实现定向授权。标准实现流程属主应用通过fileUri.getUriFromPath()将沙箱路径转为 URI构建Want对象填入 URI、MIME 类型通过flags字段显式授予权限FLAG_AUTH_READ_URI_PERMISSION授予读权限FLAG_AUTH_WRITE_URI_PERMISSION授予写权限调用startAbility拉起目标应用系统校验属主身份合法后向目标应用临时授予对应权限目标应用退出后系统自动回收权限管控要点只能授权自己沙箱内的文件不能把别人的文件再授权出去权限精确到单个文件无法一次性授权整个目录目标应用只能通过 URI 访问无法获取真实物理路径3.3 ShareKit 系统分享标准化全场景分享ShareKit是系统级分享入口在 URI 授权的基础上做了业务层封装同时支持同设备、跨设备分享权限由系统统一调度。权限管控特点配置即授权通过fileShareOptions配置读写权限、有效期系统自动完成权限授予开发者无需手动处理 Flag多形态适配碰一碰、近邻分享、应用内分享所有分享形态复用同一套权限规则跨设备同步授权跨设备分享时分布式软总线传输文件的同时权限同步授予对端应用传输完成后按规则回收高级安全能力支持加密分享、时效分享、水印保护系统级保障文件安全补充共享目录与捐献目录从 API 23 开始系统支持应用配置专属共享目录进一步收敛分享范围防止敏感文件意外泄露应用在module.json5中配置share_files目录只有该目录下的文件可被分享出去API 26 新增捐献目录可向系统文件管理器开放用户可通过系统文件管理器访问该目录本质是在沙箱内部再划一道安全边界将“可分享数据”与“内部敏感数据”物理隔离四、底层安全设计的五大原则整个沙箱与权限体系的设计始终遵循五条核心安全原则从架构层面保障数据主权默认零信任应用之间默认完全不可见、不可访问任何跨应用交互都必须经过显式授权最小必要只授予完成业务必需的最小权限范围、最短有效时长、最少操作权限用户主权所有文件级授权必须有用户明确的交互确认点击选择、点击分享禁止后台静默授权权限不可转授接收方只能自己使用权限不能二次分发避免权限无限扩散生命周期自动回收临时权限随应用生命周期自动失效避免永久遗留的权限泄露风险五、开发最佳实践与避坑指南5.1 最佳实践优先使用系统选择器公共文件访问优先用 Picker无需申请权限合规风险最低用户体验也最统一。永远用 URI 传递文件所有跨应用、跨进程文件传递一律使用 File URI绝对不要传递物理路径字符串。按需授予权限只读场景绝不授予写权限临时够用就绝不申请持久化授权权限范围越小越安全。共享目录收敛数据把可对外分享的文件统一放到共享目录中避免内部配置、日志、缓存等敏感文件被意外分享。敏感文件不跨应用分享Token、密钥、用户隐私数据尽量留在应用内部处理不要通过文件方式跨应用传递。5.2 常见踩坑直接传沙箱路径对方打开失败沙箱路径仅当前应用有效跨应用必须通过fileUri.getUriFromPath转为标准 URI否则必然触发权限拒绝。保存 URI 下次使用失效选择器、单次分享获得的都是临时授权应用退出后权限自动回收。需要长期访问必须走persistPermission持久化授权流程且需用户确认。试图路径遍历突破沙箱系统内核层会做路径规范化校验../、符号链接都无法突破沙箱边界属于无效操作。选择器拿到的 URI 无法二次分享从 Picker 获取的 URI 只有当前应用的临时访问权不具备再授权能力。要分享给第三方需要先持久化授权或将文件拷贝到自身沙箱后再分享。授权整个目录URI 授权默认仅支持单个文件目录级授权需要使用目录选择器并配合持久化权限不能通过单文件 URI 推导目录权限。总结CoreFileKit 配合沙箱隔离与 URI 临时授权本质上是将文件共享的控制权从应用收归到系统和用户手中应用不再能拿到全局存储权限只能在用户明确授权的范围内、限定的时间内访问指定的文件。这套机制虽然在开发上增加了一定的规范约束但从架构层面解决了长期困扰移动生态的存储权限滥用问题既保障了用户隐私安全也通过标准化的接口降低了合规开发成本。理解这套权限管控逻辑不仅能避免绝大多数文件访问的异常报错也能让应用的隐私合规设计更合理。
