多用户执行时CMake configure_file()的权限异常问题咨询

我遇到过完全一样的场景——共享开发机上多用户共用大体积仓库，组权限都开了但切换用户构建就触发Operation not permitted，折腾了好久才搞清楚根因，给你几个可行的解决思路：

问题本质：configure_file()的原子替换机制触发权限限制 #

CMake的configure_file()看似只是复制模板文件，但它默认会用原子替换的方式更新已有文件：先把模板内容写到一个临时文件，再用rename()系统调用替换目标文件。而Linux下的rename()操作有个容易被忽略的权限规则：

如果目标文件已经存在，执行rename的用户必须是该文件的所有者，或者拥有CAP_FOWNER权限（普通用户没有这个权限）。

哪怕你给文件开了g+rw的组权限，只要原文件的所有者是之前构建的用户，新用户就没法通过rename替换它，这就是报错的根本原因。

可行解决方案 #

1. 预清理生成文件，跳过原子替换（快速临时修复） #

既然问题出在替换已有文件，那我们可以在执行configure_file()前先把目标文件删掉，让CMake直接创建新文件而不是替换。

你可以封装一个宏来批量处理：

macro(configure_file_with_clean INPUT OUTPUT)
  # 先删除目标文件，如果存在的话
  file(REMOVE ${OUTPUT})
  # 再执行原本的configure_file逻辑
  configure_file(${INPUT} ${OUTPUT} ${ARGN})
endmacro()

然后把hiredis里的configure_file(hiredis.pc.in hiredis.pc @ONLY)替换成：

configure_file_with_clean(hiredis.pc.in hiredis.pc @ONLY)

这个思路和你找到的帖子一致，亲测有效——因为新用户有组写权限，能创建新文件，不会触发rename的权限检查。

2. 每个用户使用独立的构建目录（长期最优方案） #

这是最稳妥的解决方式，彻底避免权限冲突：

• 每个用户在自己的主目录下创建独立的build目录，比如：

  mkdir -p ~/my_project_build
  cd ~/my_project_build
  cmake -S /path/to/shared/repo -B .
  make
  

  这里-S指定共享的源码目录，-B指定自己的构建目录。

这样每个用户的构建产物都是自己的，完全不会互相干扰，也不用修改共享仓库里的任何文件。虽然每个用户会占用一点磁盘空间，但相对于40GiB的仓库，构建目录的体积通常可以忽略不计。

3. 调整目录权限与ACL（不推荐，有安全风险） #

如果你实在不想用独立构建目录，可以尝试给构建目录设置setgid位和默认ACL：

# 设置目录的setgid位，让新文件继承目录的组
chmod g+s /path/to/shared_build_dir
# 设置默认ACL，让组用户对新创建的文件有读写权限
setfacl -d -m g::rwx /path/to/shared_build_dir

但这个方案只能解决新创建文件的权限问题，已存在的旧文件（所有者是其他用户）还是会报错，而且在共享机上开这么宽松的权限容易误修改他人的构建产物，安全性不高，不推荐使用。

总结 #

优先推荐用「独立构建目录」的方案，从根源上避免权限问题；如果临时需要共用构建目录，用「预清理生成文件」的宏来快速修复。

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