关于使用std::filesystem安全创建目录以规避SonarQube权限风险的技术问询

我最近对比了POSIX mkdir、std::filesystem::create_directory、std::filesystem::create_directories的规范描述，结合SonarQube规则2612（Setting loose POSIX file permissions is security-sensitive）的要求——在Unix文件系统权限中，"others"类别指除所有者和所属组成员外的所有用户，给这个类别授权可能导致文件/目录被未授权访问，进而引发敏感信息泄露、服务中断或权限提升等风险，SonarQube会标记使用S_IRWXO的mkdir等调用——发现基于C++ <filesystem>的实现似乎没法安全规避这个问题。

按照我的理解，使用<filesystem>有两种可选方案，但都存在安全隐患：

• 方案一：先调用无属性复制的简单创建，再执行std::filesystem::permissions
  这种方式存在明显的竞争条件：在目录创建完成和权限设置完成的时间窗口内，攻击者可能滥用已创建的目录。而且<filesystem> API基于文本路径，两次调用之间，路径指向的实际目录可能被篡改，导致后续的权限设置操作失效。
• 方案二：以权限正确的目录为模板复制属性
  这个方案要求预先存在一个权限符合要求的源目录，使用起来限制很多；而且源目录的属性可能在被查询到作为新目录模板的这段时间内被篡改，同样存在安全风险。

除此之外，我还发现几个更底层的问题：

• <filesystem>完全没有覆盖mkdirat的功能，基于文本路径的API在函数执行期间，路径组件的“含义”可能被篡改，导致操作指向的对象发生变化，带来安全隐患。
• 顺带一提，cppreference.com和规范草案关于Windows平台的行为描述存在差异。

虽然SonarQube的规则看起来可以通过忽略create_directory的告警、检查后续的permissions调用来覆盖，但底层的安全风险其实依然存在。

我现在有两个核心疑问：

1. 有没有办法能安全使用<filesystem>来规避这个权限安全问题？
2. 为什么create_directory/create_directories会被设计成这样？

内容来源于stack exchange