我想了解如何为文件夹或文件授予 777 权限。我做了一些研究，了解到 777 权限在安全性方面并不是最好的。参考 Web 应用程序目录/文件。
我确实理解第一组数字，即所有者和组，但是我想澄清一下向其他人授予 7 个权限。其他人是谁，服务器内的用户？还是任何人（甚至通过浏览器访问网站的公共用户）？如果网站文件夹/文件具有 777 个权限，其他人又会造成什么类型的威胁？
在某些情况下，可以授予文件夹/文件 777 权限吗，比如图像示例，还有其他情况吗？
答案1
服务器内的其他人是谁？
其他用户是非系统用户，不属于所有者和/或组。公共用户（例如浏览者）通过进程（例如 apache httpd）访问系统上的文件。进程由用户所有，并根据访问时与用户相关的权限授予对文件的访问权限。
在某些情况下，可以授予文件夹/文件 777 权限吗，比如图像示例，还有其他情况吗？
在正确配置的系统上，很少文件需要为 777。最小特权应始终适用。例如，当图像不可执行时，为什么要授予其执行权限？为什么要授予其他可执行文件的写权限？
答案2
权限 777 当然并不意味着
任何人（甚至通过浏览器访问网站的公共用户）
可能会改变您的文件。
这确实意味着任何人在系统上可能会这样做 - 这可能是许多第三方。假设你有一个被黑客入侵的 Wordpress 网站，这只是众多网站中的一个，该网站在 apache 或指定的系统用户上运行 - 此站点可用于迭代系统以查找任何可访问（可读、可写、可执行）文件 - 猜猜谁在里面？
因此，请遵循一般建议，仅为系统运行所需的部分（无论它是什么）提供最低限度的权限。777除非私有非秘密/tmp类型的文件外，很少使用权限。
答案3
考虑任何服务帐户代表用户对您的文件执行的操作，包括这些文件内的任何 system() 调用。要利用 777 权限，只需破坏系统上的一个帐户即可。
仅凭这一事实，就足以让您在系统中遇到任何其他类别的潜在危险。代码是否容易受到缓冲区溢出和任意执行的影响？程序是否容易受到允许特权升级的 SUID/GUID 漏洞的影响？（我在这里想到的是 KDE eFax）
适当的许可可以尽可能地减轻此类风险。