Linux VM通过NFS3.0挂载Azure Blob Storage Container后访问共享文件夹Permission denied

问题描述

如图所示，/root-squash是一个Blob Storage Container的挂载点。ls -al查看该目录的权限为：
drwxr-xr-- 2 root root 0 Jun 23 23:15 root-squash
当前用户身份为root，但在尝试进入该目录时失败，报错信息为：-bash: cd: root-squash: Permission denied

调查过程

猜测

NFS server和client是两套独立的用户身份和ACL控制，因此server可以通过配置root-squash选项来定义client上的用户身份如何映射到server。

• no_root_squash：登入 NFS 主机使用分享目录的使用者，如果是 root 的话，那么对于这个分享的目录来说，他就具有 root 的权限！这个项目『极不安全』，不建议使用！
• root_squash：在登入 NFS 主机使用分享之目录的使用者如果是 root 时，那么这个使用者的权限将被压缩成为匿名使用者，通常他的 UID 与 GID 都会变成 nobody 那个系统账号的身份。
• all_squash: 与上述root_squash差别不详，实测root在Container上映射为other。

通过NFS挂载的共享目录，实际的文件系统操作都是通过RPC完成。猜测该现象是由于root-squash配置导致，以下是验证过程。

验证过程

root-squash选项值设置为root squash，ACL为754，此时访问该目录Permission denied。

在ACL配置中给other加上execute权限后，cd root-squash成功。

通过tcpdump抓取网络包进一步观察。
可以观测到，ls、cd等操作都会被转换为对应的RPC，所有的状态都存储在服务器。

其中cd进入文件夹的操作被转换为Access Call，其中包含当前客户端及当前用户UID,GID。服务器根据root squash的配置，将client映射为对应other的身份，并查询相应ACL，最终返回Access Denied。client端接收到响应，将cd的执行结果置为Permission denied。