![/var/www 中的 Linux 权限:我可以使用哪些设置来获得良好的安全实践并保持可访问性?](https://linux22.com/image/629905/%2Fvar%2Fwww%20%E4%B8%AD%E7%9A%84%20Linux%20%E6%9D%83%E9%99%90%EF%BC%9A%E6%88%91%E5%8F%AF%E4%BB%A5%E4%BD%BF%E7%94%A8%E5%93%AA%E4%BA%9B%E8%AE%BE%E7%BD%AE%E6%9D%A5%E8%8E%B7%E5%BE%97%E8%89%AF%E5%A5%BD%E7%9A%84%E5%AE%89%E5%85%A8%E5%AE%9E%E8%B7%B5%E5%B9%B6%E4%BF%9D%E6%8C%81%E5%8F%AF%E8%AE%BF%E9%97%AE%E6%80%A7%EF%BC%9F.png)
我主要想在 /var/www 中设置权限。我们使用的项目格式具有以下每个项目的共同结构:
- /var
- /万维网
- /运行
- /共享
- /project.com
- /应用
- /静止的
- /服务
- /支持
- /site.com
- /应用
- /静止的
- /服务
- /支持
- /运行
- /万维网
现在:
- Web 服务器 (nginx) 是所有目录的主要所有者
- /共享目录主要包含任何应用程序可以使用的库/库代码。
- /应用由任何项目目录根目录中的文件启动(例如 site.com)
- /静止的有子目录,通常是 /img、/css、/js、/feed 。这些可能无法执行。
- /服务包含直接运行的 Web/系统服务(子域名绕过根文件)
- /支持包含仅由应用程序加载但永远不应提供的文件。(类、模板等)
我能够让它正常工作,但我相当肯定我做得不够好。755 太多了;我对粘性位了解甚少,我打算深入研究一下。
在开发服务器上,大部分内容归 nginx:dev 所有,其中 nginx 也属于 dev 组。在暂存区中,它是 nginx:admin;在生产区中,它是 nginx:appupdater
我今天的主要目标是希望开发人员小组能够创建和编辑项目目录(project.com、site.com 等)中的任何文件,而 /shared 目录只需极少手动更新。
首先,我希望设置权限,使新文件归 nginx:devs 所有,开发人员可以在开发服务器上自由上传和更改它们。我试图尽可能地获得拒绝访问的权限,同时允许运行的应用程序(作为 nginx)从支持和应用程序目录中加载文件。唯一的例外是需要在 /static/upload 和 /support/generated 文件夹中写入
我如何才能从权限方面确保安全,以便我们仍然可以运行应用程序,允许开发人员访问和创建文件而不覆盖所有者:组,并且如果用户上传可执行文件,通常不会自食其果?
(除了帮我检查应用程序/服务器之外)
答案1
很久以前,我就得出结论,在用户群中共享 Web 项目的最佳方式是强制他们使用sudo
或ssh
始终以用于所有项目文件的单个开发用户身份登录。如果您需要跟踪各个开发人员的更改,最好让他们在自己的环境中工作,这样上述方法将适用于发布工程而不是开发人员。
您sudo
可以使用 授予用户访问系统组的权限,然后将用户添加到该组。ssh
您需要将用户 SSH 密钥直接添加到 dev 用户的.ssh/authorized_keys
。
在此之前,我尝试了许多使用权限和 posix 草案 ACL 的技术,但结果证明它们毫无用处。尤其是设置文件的执行位是为所有者保留的,这就是为什么我希望所有用户在进行任何修改之前切换到所有者 UID。
他们还对正在进行的项目和主目录有一个概念,因此维护共享资源变得更加容易。
然后,应用程序可以在不同的用户(可能在同一个组中)下运行,该用户仅具有对除您提到的目录之外的数据的读取权限。在或多或少的单用户环境中,您不需要粘性位。它旨在保护tmp
目录中的文件不被非所有者访问。
理论上的解决方案是使用功能强大的 ACL 系统(如 NFSv4 ACL),但通常没有对该系统的原生支持。虽然有补丁,但您可能不想花时间处理这个问题,最终会得到一个比我上面描述的更复杂的解决方案。