freenas windows acls文件夹权限

我们有FreeNAS-9.2.1.3-RELEASE-x64提供一个samba共享给IIS(由2012 R2托pipe,如果这是相关的)

ssasan01# smbd --version Version 4.1.6

freenas服务器连接到由Windows服务器提供的AD。 域名是“AD”。 IIS站点作为该站点特有的活动目录用户运行。 应用程序池(每个站点都有自己的身份)和IIS中站点的“物理path凭据”都configuration为相同的活动目录用户。

大多数情况下,除了文件夹创build之外,一切正在运行 在一个文件夹中,IIS用户可以访问(写入/修改/读取/执行)(实际上是应用程序数据)应用程序代码尝试使用DirectoryInfo创build文件夹。创build生成的文件夹在磁盘上成功创build并显示为inheritance来自父级的ACL权限,但是create调用返回一个错误。

 Access to the path --snip--\App_Data\packages\created\__testFolder__ is denied. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.UnauthorizedAccessException: Access to the path --snip--\App_Data\packages\created\__testFolder__ is denied. 

日志samba日志中出现以下错误(由于这是生产服务器,因此当前级别为1)

Sep 8 17:28:05 ssasan01 smbd[54843]: [2014/09/08 17:28:05.026127, 0] ../source3/smbd/open.c:543(change_dir_owner_to_parent) Sep 8 17:28:05 ssasan01 smbd[54843]: change_dir_owner_to_parent: failed to change current working directory to --snip--/App_Data/packages/created/__testFolder__. Error was Permission denied

(–snip–replace基本path)

文件似乎正常工作。 如果我通过SSH查看创build的文件夹,我看到这个:

dw-rwx---+ 2 AD\applicationpoolidentity group 2 Sep 8 17:28 __testFolder__

(AD \ applicationpool身份是用户为该网站,组是相同的其他文件夹)

如果我尝试使用Windows资源pipe理器以有权访问共享的用户身份(以及写入有问题的文件夹的写入权限)的身份login时创build文件夹,则会发生同样的错误/问题。 该文件夹,至less根据Windows,被设置为inheritance权限。 在这种情况下,新创build的文件夹没有得到任何ACL分配给它(资源pipe理器没有权限创build的文件夹),但我怀疑这很可能是由于操作顺序types的问题,因为当IIS / .net在另一个场景中创build文件夹,事情发生的顺序与通过资源pipe理器创build文件夹的顺序不同。

我已经手动检查了smb.conf文件,以消除潜在的GUI问题,这里是我认为可能与search谷歌这一问题有关的任何。 我在testing时添加了“强制创build模式”和“强制目录模式”。

 unix extensions = no acl check permissions = true acl map full control = true create mask = 0666 directory mask = 0777 force create mode = 0666 force directory mode = 0777 inherit owner = yes inherit permissions = yes inherit acls = yes writeable = yes browseable = yes 

注意:所有文件夹和文件都是通过samba客户端(不是直接从linux shell)创build的,可以通过作为拥有该文件夹权限的用户执行的IIS代码,也可以通过Windows资源pipe理器窗口以用户身份login到服务器创build文件和文件夹的权利。 文件似乎正常工作。

由于ZFS快照和冗余,我们在这里使用freenas,它也为其他机器提供NFS服务,为其他机器提供NFS服务,所以用基于Windows的文件服务器(或者另一个SAN / NAS服务器)replace这个服务器,而不是不可能的,这不是一件容易的事。

一个可能的奇怪之处在于,整个树的所有文件夹和文件的所有者是pipe理员级别的用户(而不是pipe理员!),以便我们能够以pipe理员身份访问和更改权限。

更新1:从日志中的错误工作,它看起来像文件夹已成功创build,但然后桑巴进程没有权限更改到该文件夹​​为了设置权限。 父文件夹(在这种情况下,“创build”)configuration了以下掩码: d---rwx---+ 。 如果我chmod 777 created (我试图创build新的文件夹内的文件夹)然后IIS进程(和Windows资源pipe理器)都可以创build和删除该子目录中成功的文件夹。

我们正在testing两个不同的进程:当使用Windows资源pipe理器进行testing时,我以域用户身份login到Windows,这是父文件夹的“所有者”和“组”。 同一个用户也通过ACL授予完全控制权。 组通过掩码有rwx。 当通过.net / IIS进行testing时,池作为用户进行写入/修改/读取(除完全控制以外的所有内容)通过ACL授予。 此用户不是所有者或组,并且没有面向每个人的屏蔽权限。

错误消失,一切工作正常,如果我chmod 777是直接的父母的文件夹我试图创build一个。 我不认为这解决了这个问题,因为它是不安全的,尤其是考虑到我们使用完整的ACL。

更新2 007工程,000失败 – 似乎公共掩码位在这里使用,无论ACL和不pipe用户共享访问。 这是因为访问共享的用户不是所有者或组? 我们不希望将所有站点用户添加到组中,并通过unix掩码给组写入信息,因为这会导致path遍历安全漏洞(一个站点用户可以访问所有其他站点文件夹,因为他们是一个成员的组),不是吗? 我们可以有select性地使用“所有者”'700',并将站点的根目录和他们的子项目传送给站点用户,但是这看起来很难维护,并且绕过了ACL和inheritance的使用。 或者是007/777在这种情况下是安全的,因为使用ACL作为另一层?

Update 3检查了open.c的samba源代码,看看change_dir_owner_to_parent实际上在做什么。 首先,它使用getwd获取文件夹(根据getwd_cachecaching),然后执行一个cwd到该文件夹​​中以“locking”它,使得所有者更改不处于竞争状态。 这是我的testing似乎失败的地方。 在之前的testing/更新中,我发现如果我将xx7赋予任何东西,那么它仍然可以工作,并且即使在我再次将所有人遮罩掉之后仍然可以继续工作。 我认为这是caching权限检查,所以一旦caching过期/无效问题将重新发生。 我不确定哪个cachingvariables适用于此。 我发现一个文件夹不工作(有070),并确认我无法正确创build新的文件夹。 然后我用chmod来授予074到文件夹,并确认这解决了这个问题。 所以这比777好,但仍然不确定为什么这甚至是必需的? 我需要chmod -R 074 *整个份额吗?

更新4find另一个被破坏的文件夹(070) – 通过使用CMS用户界面确认已损坏,并创build了一个文件夹,确认创build该文件夹的进程不起作用。 然后通过SSH将chmod 000应用到父项。 现在该过程成功创build文件夹。 到底是怎么回事?! 我没有触及任何这些testing的Windows ACL。

更新5用尽损坏的文件夹testing…拿了一个文件夹是070,不工作(在CMS中validation),然后chmod 070它(与目前相同的权限),现在我可以通过文件夹内创build项目CMS(使用Windows ACL提供的权限)所以,如果我chmod破碎的文件夹 – 任何东西,然后开始工作?

这是因为这个

 dw-rwx---+ 2 AD\applicationpoolidentity group 2 Sep 8 17:28 __testFolder__ 

只代表所有者。 您看到位掩码结尾处的“+”? 这意味着,有一个(Windows)ACL控制访问。 所以,如果你有权访问一个文件,因为你使用的是r / w的acl,所有者的位掩码不适用于你(除非你所有者)。 如果你不明确地在acl中,007工作,因为这意味着“除了所有者用户之外的任何人,除了所有者组都可以访问该文件”。

在早期版本的FreeNAS中,可以使用“ls -v”来探索ACL。 可悲的是,这不再工作。 我还没有发现如何从unix方面探索这个。

HTH