open_by_handle_at(2)系统调用的设计初衷及常见用法是什么？

设计定位 #

open_by_handle_at(2)是Linux内核在2.6.39版本引入的特权系统调用，最初的设计目标是为用户态网络文件服务程序提供内核级的持久化文件标识能力。
它允许特权进程获取与路径无关、跨进程/跨挂载周期唯一对应的文件句柄，也可以通过该句柄直接打开对应文件，不需要依赖文件的完整路径解析，解决了此前用户态文件服务只能通过路径标识文件、遇到文件重命名/移动就会访问失效的痛点。默认情况下，调用该系统调用需要进程持有CAP_DAC_READ_SEARCH特权，普通用户进程无权限使用。

典型通用使用场景 #

• 用户态网络文件服务实现：NFSv4、Samba等网络文件服务的协议本身就是用持久化句柄标识文件，open_by_handle_at(2)推出前只有内核态服务可以使用这类能力，推出后用户态实现的文件服务也可以直接生成符合协议要求的文件句柄，大幅降低了路径解析开销，也避免了文件路径变化导致的客户端访问异常。
• 备份类工具开发：备份软件运行时可以通过该调用获取待备份文件的唯一标识，备份周期内即使文件被用户移动、重命名，也可以通过句柄快速定位到目标文件，不需要重复扫描目录树更新路径映射。
• 高性能文件索引服务：特权运行的全局文件索引、全文检索工具，可以用文件句柄作为索引的主键，用户批量修改文件名时，只需要更新句柄对应的路径字段即可，不需要重建全量索引，大幅提升索引更新效率。
• 分布式文件系统客户端实现：集群分布式文件系统的用户态客户端，可以通过该调用同步内核维护的全局文件唯一标识，保证集群内不同节点访问同一个文件的一致性。

和容器逃逸的关联说明 #

open_by_handle_at(2)被广泛用于容器逃逸POC的核心原因，是它拿到的文件句柄是宿主机内核的全局标识，不受容器Mount Namespace的隔离限制。只要容器被错误配置了CAP_DAC_READ_SEARCH特权，攻击者就可以在容器内构造宿主机文件对应的句柄，直接绕过容器挂载隔离访问宿主机文件系统，进而实现逃逸。
需要注意的是，该系统调用本身的设计不存在安全缺陷，容器逃逸的根因是容器被赋予了不必要的高权限，默认配置的容器不持有CAP_DAC_READ_SEARCH权限，无法利用该方法实现逃逸。

内容的提问来源于stack exchange，提问作者Cipher