用户不是登录到您的应用程序的人 – 他们在应用程序中的角色(管理员等)与该方案完全无关.用户是进程运行的linux系统用户.您网站的代码仅作为一个用户运行 – 它可能是您的网络服务器的用户(这不是一件好事),或者它可能是您网站特定的用户(这要好得多).

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

一个好的设置将使您的服务器作为一个用户运行(让我们称之为用户’webserver’)并且您的动态脚本语言(例如通过FastCGI)作为其自己的用户运行(每个站点一个用户 – 让我们调用我们的第一个用户’site1′) .

要为您的文件提供服务,Web服务器需要访问它们,并且脚本语言需要访问它们.这意味着：’site1’和’webserver’需要能够读取您的文件.但是只有其中一个可以“拥有”文件.所有者是“用户”(用户,组,其他).我们还需要我们的脚本语言才能写入目录(并读取它编写的文件).因此,用户’site1’需要读写权限.由于我们希望组和其他权限尽可能具有限制性,因此我们的“所有者”将为“site1”,并且相应的用户权限将被读取和写入.

由于我们无法将我们的网络服务器的权限指定为另一个“用户”,我们会将“网络服务器”添加到“网站1”组(当然,您可以创建一个包含“site1”和“网络服务器”的不同组.该组的成员将获得相同的权限.最宽松的权限(用户,其他集)将应用于任何给定用户以确定其权限.

值得注意的是,良好的设置不应要求文件具有动态语言的执行权限.这些文件不是直接运行的,而是读入解释器 – 只需要读取权限来运行一个典型的脚本(一个不写任何东西的脚本).

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

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

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

>用户上传静态文件(images / swf / js文件)的目录中的文件将驻留：640
>管理员上传的静态文件(images / swf / js文件)所在目录中的文件：640
>应用程序中使用的库所在目录中的文件：400(或440)
>可执行/可浏览服务器端脚本所在目录中的文件：400(或440)
>目录中的文件,其中已存在的文件(txt或xml)将由服务器端的代码编辑：640或600

>(取决于Web服务器是否会显示这些,有时不修改)

虽然,最小目录权限可能是：

>用户上传的静态文件(images / 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).

(显然你需要写入权限来上传文件 – 但是如果你愿意,你可以删除那些文件 – 可以说,如果有人正在写一个只有所有者可以写的目录 – 你的帐户已被盗用 – 这是一个保持限制权限的原因).