【问题标题】:IIS application cannot access path despite giving "Everyone" access尽管授予“所有人”访问权限,IIS 应用程序仍无法访问路径
【发布时间】:2013-07-11 09:32:18
【问题描述】:

IIS 应用程序似乎无法写入临时文件夹(需要使用 Excel 互操作)。

对路径“C:\Temp\temp_file_name.xlsx”的访问被拒绝。

异常详细信息:System.UnauthorizedAccessException:访问 路径 'C:\Temp\temp_file_name.xlsx' 被拒绝。

这是堆栈跟踪:

 [UnauthorizedAccessException: Access to the path 'C:\Temp\temp_file_name.xlsx' is denied.]
    System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) +10550675
    System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite) +863
    System.IO.File.Copy(String sourceFileName, String destFileName) +12
    ExcelOperations.FileHelper.CopyFile(String sourcePath, String destinationPath) +477
    WebExtensions.PersonalPriceListDataExchange.CreateNewQueryBtn_Click(Object sender, EventArgs e) +427
    System.Web.UI.WebControls.Button.OnClick(EventArgs e) +115
    System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) +140
    System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +29
    System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2981

现在,从所有人的角度来看,这看起来像是典型的“缺少权限”案例,但我已经修改了 Temp 文件夹以允许特殊组“Everyone”完全访问...

可能缺少什么?

编辑:

忘记说了!

当我使用管理帐户登录该站点时,该应用程序可以运行。但是,任何其他帐户(尽管成功登录 IIS 站点)都无权访问该文件夹。同样,奇怪的是我已授予“所有人”完全访问权限,但仍然无法正常工作。

有问题的应用程序是 MS CRM 4.0 扩展(位于 CRM ISV 文件夹内,因此它是一个子站点),使用与 CRM 本身相同的应用程序池。但是,我怀疑这是否与 CRM 本身有关。我认为这可能是 IIS / 权限问题。

编辑 2:

我在我的应用程序中添加了一段简单的代码:

        throw new Exception(Page.User.Identity.Name + " " + HttpContext.Current.User.Identity.Name);

显然,这会抛出当前使用的身份的当前名称。身份很好 - 即它是属于域的普通用户。我什至可以添加此特定用户并授予他对该文件夹的权限,但 它仍然失败。 :(

编辑 3:

我已打开临时文件夹的审核。

这是结果(我不得不编辑一些信息):

A handle to an object was requested.

Subject:
Security ID:        -the domain and login of the currently logged user-
Account Name:       -the current username-
Account Domain:     -the current domain-
Logon ID:       0x5e3194d

Object:
Object Server:      Security
Object Type:        File
Object Name:        C:\Temp\temp_file_name.xlsx
Handle ID:      0x0

Process Information:
Process ID:     0x13f0
Process Name:       C:\Windows\System32\inetsrv\w3wp.exe

Access Request Information:
Transaction ID:     {00000000-0000-0000-0000-000000000000}
Accesses:       DELETE
            READ_CONTROL
            SYNCHRONIZE
            ReadData (or ListDirectory)
            WriteData (or AddFile)
            AppendData (or AddSubdirectory or CreatePipeInstance)
            WriteEA
            ReadAttributes
            WriteAttributes

Access Reasons:     DELETE: Unknown or unchecked
            READ_CONTROL:   Unknown or unchecked
            SYNCHRONIZE:    Unknown or unchecked
            ReadData (or ListDirectory):    Unknown or unchecked
            WriteData (or AddFile): Denied by Integrity Policy check
            AppendData (or AddSubdirectory or CreatePipeInstance):  Unknown or unchecked
            WriteEA:    Unknown or unchecked
            ReadAttributes: Unknown or unchecked
            WriteAttributes:    Unknown or unchecked

Access Mask:        0x130197
Privileges Used for Access Check:   -
Restricted SID Count:   0

审核报告中指定的用户被授予对该文件夹的完全访问权限

【问题讨论】:

  • 你的文件的文件名是什么?看来您正在尝试编写 '' ?文件名中不允许使用 字符。
  • 我显然已经从异常中清除了文件名,因为我无法分享我正在处理的太多内容。这是一个普通的 Excel 文件名。
  • 您是否尝试过重启 IIS?
  • 抱歉,不要认为这太明显了,Excel 文件名有什么秘密?而且我认为值得一提,因为通过您所做的替换,您正在创建非法文件名,这可能是您问题的一部分。
  • sigh 文件名包含客户端的名称。我认为这足以隐藏文件名。它不包含非法字符。

标签: c# iis-7


【解决方案1】:

这里有一些想法......

  • 显然,让每个人都可以访问该文件夹是不好的。您应该检查您的应用程序池正在运行的凭据。例如,如果它是“应用程序池身份”,您只需授予名为 IUSR 之类的用户访问该文件夹的权限。

  • 其中一个奇怪的错误是,您看到的错误也可能是尝试写入空文件(零字节)的结果。我记得有“权限”问题,实际上是零字节文件写入。

  • 奇怪的是,应用程序用户登录如何改变服务访问的行为 - 你是在模拟吗?即您是否将 Windows 登录信息传播到服务?如果是这样 - 可能是错误是因为用户来自另一个域。例如,如果用户来自域 MYDOM,我认为 Everyone 组也必须来自该域(请注意,还有“本地域”,例如您的 PC 名称 - 例如,MYPC\Administrator 是本地用户并且与 MYDOMAIN\Administrator 没有任何关系)。

  • 最终,您可能想要更改 Temp 文件夹的位置。您正在使用 C#,因此类似于:

    System.IO.Path.GetTempPath()

可以做到这一点,因为 IIS 已经有一个预定义的路径,仅用于这些目的,您将拥有写访问权限。不用说,这比使用带来严重安全风险的C:\Temp 更好。

【讨论】:

  • 我一定会尝试GetTempPath() - 我完全忘记了这一点。但是,关于其他想法......如果它不适用于每个人,为什么它会适用于特定用户?复制文件时发生错误 (File.Copy(source, destination)),因此它不是 0 字节文件。是的,可能会发生假冒行为——我猜这是 CRM 所做的。但是用户来自同一个域 - 否则他们无法登录 CRM。
  • 使用GetTempPath() 产生了C:\Windows\Temp,而且我在那里也没有写入权限。 :(
  • 您是否尝试过对文件夹启用广泛审核? (在文件夹属性/安全选项卡/高级/审核...)这是一个很长的镜头,但它可能会给你一些提示谁在尝试做什么,即正在使用哪些凭据和/或为什么它失败了......或者如果应用程序能够访问该文件夹...
  • 审计是个好主意 - 我已将结果添加到问题中。
【解决方案2】:

我建议你给你的 apppool 管理员权限。它会解决你所有的问题。

【讨论】:

  • 虽然我很乐意这样做,但我宁愿最终拥有一个安全的系统,而不是一个不安全的系统。将管理员添加为应用程序池身份听起来是个坏主意。但是,出于测试目的,我绝对可以这样做。
  • 是的,这样做是为了测试。但我认为如果你正在做与 ms office 相关的编码,那么你可能会面临很多与权限相关的问题。
  • 我很清楚这一点。我想更改代码以使用 OpenXML 库而不是 Interop 但正在修改的 Excel 文档结果要复杂得多,并且使用 OpenXML 进行的修改不会刷新文档中的所有链接单元格。
  • 我尝试过使用系统帐户。没有变化,问题仍然存在。
  • 嘿,我之前已经遇到过同样的问题。而是使用 netoffice.codeplex.com 制作 excel doc 。它不会在托管时产生任何权限问题。
【解决方案3】:

好的,虽然我仍然不知道为什么在所描述的场景中我无法访问该文件夹,但关闭 IIS 应用程序的模拟访问会有所帮助。

【讨论】:

    【解决方案4】:

    您是否同时启用了匿名和 Windows 身份验证?将有助于解释为什么它在模拟关闭时起作用。

    【讨论】:

    • 否 - 它启用了 Windows 身份验证和模拟。删除 Impersonation 并仅依赖 Windows 身份验证清除了一切(尽管现在文件访问仅基于应用程序池标识,但在这种情况下这不是问题)。
    猜你喜欢
    • 2016-07-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-07-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-08-06
    相关资源
    最近更新 更多