![使用 shell 脚本的 Cron 作业修复 SFTP 目录和文件所有权](https://linux22.com/image/796888/%E4%BD%BF%E7%94%A8%20shell%20%E8%84%9A%E6%9C%AC%E7%9A%84%20Cron%20%E4%BD%9C%E4%B8%9A%E4%BF%AE%E5%A4%8D%20SFTP%20%E7%9B%AE%E5%BD%95%E5%92%8C%E6%96%87%E4%BB%B6%E6%89%80%E6%9C%89%E6%9D%83.png)
我们的 SFTP 共享设置在:/home/COMMUNITY
每个工作组都有自己的目录,例如:/home/COMMUNITY/Halloween
此目录下有多个目录。有一个包含所有用户的组:COMMUNITY。所有目录都已将粘性位设置为组所有者 COMMUNITY,这很有效,并且在此结构中创建的所有目录和文件都自动具有此组。
SFTP 用户的个人目录权限由目录组控制。对于 /Halloween,该权限由组 HALLOWEEN 控制。用户使用 SFTP 登录时,从 /home/COMMUNITY 开始。当每个目录只有一个用户在从事社区项目时,这种方法很有效。但是,我们的社区服务组正在发展壮大,每个组(例如 HALLOWEEN)的用户越来越多,这时就会出现问题。默认情况下,用户创建的文件目录会自动获得其所有权。但为了使我们的系统正常运行,底层目录和文件的所有权必须属于 root。
也许存在缺陷,但我们目前的想法是使用 shell 脚本修复此问题,该脚本首先测试目录/文件是否以 root 为所有者,如果不是,则将其更改为 root。我们需要在 COMMUNITY 目录下递归执行此操作。我们希望保持此操作非常快,并且不强制更改已以 root 为所有者的文件。人们共享文档可能会产生问题,但当我们频繁运行脚本时,我们希望它能解决我们当前的问题,即用户无法保存其他用户创建的文档。
文章:“用于修复目录和文件所有权的 Bash 脚本”、“SFTP 监狱和保持文件所有权相同/每个文件夹的文件所有者”和“粘性位提示”接近我们想要的,但它不是 100% 相同,我们无法弄清楚如何使其工作。
所有使用该系统的志愿者都非常感谢您的帮助,但现在他们却发现该系统无法再正常运转,感到十分沮丧。
答案1
这听起来实际上你需要查看默认的 umask,而不是担心 chown() 文件。root 用户可以读取任何内容,就是这样(除非你将 SELinux 放入其中,但那是另一篇论文)。大多数现代 Linux 的默认 umask 为 022,这意味着你对新文件有 755 个权限。你想要 002,以获得 775 个权限,这将保留组所有权(通过你已经设置的目录粘性位)和组写入权限。用户所有者会定期更换,但这不应该是一个问题。