通常的web项目目录有什么完美的unix权限？

假设一个“web应用程序”运行在一个服务器（如apache，nginx等）上，并且是用一些dynamic的脚本语言（比如PHP，Ruby等）编写的，那么你就会误解“用户”是谁。

用户不是login到您的应用程序的人 – 并且他们在应用程序（admin等）中的angular色与场景完全无关。 用户是运行该进程的linux系统用户。 你的网站的代码只能以一个用户的身份运行 – 它可能是你的网站服务器的用户（这不是一件好事），也可能是你的网站特定的用户（这更好）。

在Linux上，用户属于组 – 我们可以将用户添加到另一个组，并为该组分配权限。

一个好的设置将让你的服务器以一个用户身份运行（让我们称这个用户为“webserver”），然后运行你的dynamic脚本语言（例如通过FastCGI）作为自己的用户（每个站点一个用户 – 我们称之为第一个用户site1） 。

要为您的文件提供服务，Web服务器需要访问它们，并且脚本语言需要访问它们。 这意味着：“网站1”和“networking服务器”需要能够读取您的文件。 只有其中一个可以“拥有”这些文件。 所有者是“用户”（在用户，组，其他）。 我们还需要我们的脚本语言才能写入目录（并读取它写入的文件）。 用户'site1'因此需要读写权限。 由于我们希望群组和其他权限尽可能限制，我们的“所有者”将是“site1”，相应的用户权限将被读写。

由于我们无法将我们的networking服务器的权限指定为另一个“用户”，因此我们将“网站服务器”添加到“网站1”组（当然，您可以创build一个包含“网站1”和“networking服务器”的不同组。这个组中的成员将被赋予相同的权限。（用户，组和其他组的权限最松散的权限）将被应用于任何给定的用户来确定他们的权限。

值得注意的是，一个好的安装程序不应该要求文件具有dynamic语言的执行权限。 这些文件不是直接运行，而是读入解释器 – 只需要读取权限就可以运行一个典型的脚本（一个不写任何东西）。

对目录的“执行”权限具有不同的含义 – 允许遍历而不能读取内容。 为了能够读取目录中的文件，用户必须在其上的每个目录具有“执行”权限。

对于Web应用程序，每个文件都必须具有所有者的读取权限 – 否则，这是一个相当无意义的文件。 无论用户还是pipe理员上传文件（通过您的Web应用程序），“所有者”（即dynamic语言）都需要写入权限。 一个有效的设置将尝试直接通过Web服务器提供静态文件，因为dynamic语言在读取大文件和回显内容时往往会很慢。 因此，Web服务器需要读取访问您的静态文件。

因此，最小的文件权限可能是：

• 用户上传静态文件（images / swf / js文件）的目录中的文件将存在：640
• pipe理员上传静态文件（images / swf / js文件）的目录中的文件将存在：640
• 位于应用程序所用库的目录中的文件：400（或440）
• 可执行/可浏览的服务器端脚本将驻留的目录中的文件：400（或440）
• 在已经存在的文件（txt或xml）的目录中的文件将由服务器端的代码编辑：640或600
  • （取决于networking服务器是否显示这些，有时不修改）

而最小的目录权限可能是：

• 用户上传静态文件（images / swf / js文件）的目录将位于：750
• pipe理员上传的静态文件（images / swf / js文件）的目录将驻留在：750
• 在应用程序中使用库的目录：500（或550）[至less应为510]
• 可执行/可浏览的服务器端脚本将驻留的目录：500（或550）[应该至less为510]
• 已经存在的文件（txt或xml）将通过服务器端的代码进行编辑：750或700
  • （取决于networking服务器是否将从这里提供文件，有时不修改）

再次说明 – 您的Web服务器必须对每个需要访问的目录具有“执行”权限，因此即使Web服务器不会从给定目录提供文件，我们也应该授予它执行权限。

给Web服务器读取大部分文件是很常见的（所以把这500个改成550）。 默认的“有点安全”的权限通常是755的目录和644的文件 – 没有执行权限，每个人都可以阅读，只有用户可以写 – 你会注意到，Linux系统上的绝大多数文件具有这些权限。

请记住，“其他”权限是指不是所有者或组中所有系统用户（即所有剩余的系统用户）的权限。 保持你的'其他'权限限制是好的，因为这些用户是一个未知的 – 你没有明确给他们的权限。 其他许可通常是在受损系统上最容易利用的（例如，/ tmp是普通目标的原因之一）。

在上述背景下，我不认为你最后两个问题是相关的。 将您的目录权限设置为550（并将文件权限设置为440），然后授予用户对应用程序将要写入的任何目录（即目录：750;文件：640）的写入权限。

（你显然需要写权限才能上传这些文件 – 但是如果你愿意的话，你可以在之后删除这些文件 – 可以说，如果有人正在写一个只有所有者可以写入的目录 – 你的账户已经被入侵 – 这是一个保持限制性权限的原因）。

拥有完成工作的最小权限集合是正常的。 如果你有你的networking服务器和用户共享一个共同的组，那么你可以删除需要任何访问o 。 权限也与用户有关。 您似乎误解了八进制权限。

1. 555是r-xr-xr-x而不是rw-rw-rw 。 因为它是一个目录然后创build/删除文件，你需要有x设置所以750 rwxr-x---将是一个很好的起点。 这允许拥有该目录的用户添加/删除文件以及公共组中的每个人都可以访问它们。
2. 与上面的1.一样。
3. 如果他们是真正的静态文件比050会给Web服务器访问，但是创build文件在首位750将是一个最低限度。
4. 与上面的3一样。
5. 070是允许networking服务器读取和更改文件的最小值，但是这些文件需要被创build，因此770可能更为现实。

一般情况下，对于目录（目录上的SGID位，对于BSD和Linux，如果使用BSD语义装入文件系统，将使用模式0755,0775或2775，这将使新文件的组关联与父目录设置匹配，而不是文件创build者的默认GID）。 这允许所有用户遍历（chdir进入和通过）并读取（运行ls命令或执行readdir / read系统调用）有问题的目录。 可选项添加组/写入选项，并且如上所述，目录上的SGID位可以帮助保留与合适组相关联的所有文件和子目录。

对于文件通常会使用0644或可能0664（世界可读和任一组可写或不可）。 显然，对于CGI脚本和二进制文件，必须添加x位; 对于一些特殊的情况，经过非常好的testing二进制文件，可能会添加SUID或SGID位。 通常，UNIX和Linux将忽略脚本上的SUID / SGID位，并只遵守其本地编译的可执行二进制文件的语义。 然而，你可能正在像Apache一样运行你的网站，有一些像“setuidhack”这样的模块，它可以使Web服务器甚至在解释的脚本上使用SUID / SGID位。 （这是通过HTTP守护进程stat（）完成每个文件并使用自己的自定义fork（）/ execve（）代码，将正确的解释器string插入到execve（）向量中，而不是简单地将可执行文件的名称直接传递给execve （）系统调用）。

这些只是最一般的指导方针。 在所有情况下，它们都不是“完美的”，您应该查阅您的Web服务器以及您正在安装和configuration的任何Web应用程序或框架的文档…并且您可能希望在您之前向UNIX安全专家咨询暴露您的任何文件，代码或服务器到公共互联网。