假设“ Web应用程序”在服务器（例如apache，nginx等）上运行，并且是用某种动态脚本语言（例如PHP，Ruby等）编写的，则您对“用户”的身份有误解。
用户不是登录到您的应用程序的人-并且，他们在应用程序中的角色（管理员等）与方案完全无关。该用户是运行该进程的Linux系统用户。您网站的代码仅以一个用户身份运行-它可能是您的Web服务器用户（这不是一件好事），或者可能是特定于您网站的用户（更好）。
在linux上，用户属于组-我们可以将用户添加到另一个组，并为该组分配特权。
良好的设置将使您的服务器以一个用户身份运行（我们称此用户为“ webserver”），而动态脚本语言（例如通过FastCGI）以其自己的用户身份运行（每个站点一个用户-我们将第一个用户称为“ site1”） 。
要提供文件，Web服务器需要访问它们，脚本语言需要访问它们。这意味着：“ site1”和“ webserver”需要能够读取您的文件。但是，其中只有一个可以“拥有”文件。所有者是“用户”（在用户，组中，其他）。我们还需要脚本语言才能写入目录（并读取其写入的文件）。因此，用户“ site1”需要读写权限。由于我们希望组和其他权限尽可能严格，因此我们的“所有者”将是“ site1”，并且将读写相应的用户权限。
由于我们无法将我们的网络服务器的权限指定为另一个“用户”，因此我们将“网络服务器”添加到“ site1”组（您当然可以创建一个同时包含“ site1”和“ webserver”的其他组。全部）该组的成员将被赋予相同的权限，（用户，组，其他集合中）最宽松的权限将应用于任何给定的用户，以确定他们的权限。
值得注意的是，良好的设置不应要求文件具有动态语言的执行权限。这些文件不是直接运行，而是被读入解释器-运行典型脚本（一个不写任何东西的脚本）仅需要读取权限。
目录的“执行”权限具有不同的含义-允许遍历而无法读取内容。为了能够读取目录中的文件，用户必须对目录上方的每个目录都具有“执行”权限。
对于Web应用程序，每个文件都必须具有其所有者的读取权限-否则，它是一个毫无意义的文件。无论用户还是管理员（通过Web应用程序）上传文件，“所有者”（即动态语言）都需要具有写权限。有效的设置将尝试直接通过Web服务器提供静态文件，因为动态语言在读取大文件和回显内容方面往往比较慢。因此，Web服务器需要对您的静态文件具有读取权限。
因此，最小文件权限可能是：
- 用户上载静态文件（images / swf / js文件）的目录中的文件将位于：640
- 管理员上载静态文件（images / swf / js文件）的目录中的文件将位于：640
- 应用程序中使用的库所在的目录中的文件：400（或440）
- 可执行文件/可浏览服务器端脚本将驻留在目录中的文件：400（或440）
- 目录中的文件，将通过服务器端的代码在其中编辑现有文件（txt或xml）：640或600
- （取决于Web服务器是否会不时显示这些内容，而有时会显示这些内容）
同时，最小目录权限可能是：
- 用户上载静态文件（图像/ swf / js文件）的目录将位于：750
- 管理员上载静态文件（images / swf / js文件）的目录将位于：750
- 应用程序中使用的库所在的目录：500（或550）[至少应为510]
- 可执行/可浏览服务器端脚本将驻留的目录：500（或550）[至少应为510]
- 服务器端代码将在其中编辑现有文件（txt或xml）的目录：750或700
- （取决于Web服务器是否会从此处提供文件，有时不做修改）
再一次-您的Web服务器必须在其需要访问的目录上方的每个目录上都具有“执行”权限-因此，即使该Web服务器不提供给定目录中的文件，我们也应为其授予执行权限。
授予Web服务器对大多数文件的读取访问权限是很普遍的（因此，请将500更改为550）。默认的“有点安全”权限通常是目录755和文件644-没有执行权限，每个人都可以读取，只有用户可以写-您会注意到Linux系统上的绝大多数文件都具有这些权限。
请记住，“其他”权限是指不是所有者或组中的任何系统用户（即，其余所有系统用户）。限制您的“其他”权限是件好事，因为这些用户是未知的-您尚未明确授予他们权限。其他权限通常是最容易在受感染系统上利用的权限（例如/ tmp是常见目标的原因之一）。
在上述情况下，我认为您的最后两个问题无关紧要。将您的目录权限设置为550（并将文件权限设置为440），然后向用户授予您的应用程序要写入的任何目录的写权限（即，目录：750；文件：640）。
（您显然需要写许可权才能上传文件-但是，如果愿意，您可以在以后将其删除-可以说，如果有人正在写一个只有所有者可以写的目录-您的帐户已被盗用-这是一个保留限制性权限的原因）。