locked
Request for the permission of type FileIOPermission failed

    Question

  • I have a ASMX Web Service that references a custom DLL we have created.  The DLL has a function to read some settings from a XML file that we deploy along with the web service on the web server.

    When I run the solution on my local machine using the web server built into VS.Net 2005, everything works great.  When I deploy it to our Web Server running IIS, I'm getting an error saying it doesn't have proper permissions to read the file.  The entire exception message is below, but it looks like it's saying the assembly that caused the failure (my custom DLL - BusinessModel.DLL) is in the MyComputer zone.  Shouldn't this mean that the assembly has unrestricted access to the file system?  I don't have any security specific stuff in my code (no attributes explicitly demanding or denying permissions).

    How can I get rid of this error so that my DLL can successfully read from the XML file?

    System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.

       at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)

       at System.Security.CodeAccessPermission.Demand()

       at System.IO.Path.GetFullPath(String path)

       at System.Xml.XmlResolver.ResolveUri(Uri baseUri, String relativeUri)

       at System.Xml.XmlUrlResolver.ResolveUri(Uri baseUri, String relativeUri)

       at System.Xml.XmlTextReaderImpl..ctor(String url, XmlNameTable nt)

       at System.Xml.XmlTextReader..ctor(String url)

       at Westeel.WesteelConfigReader.ReadSetting(String settingName) in C:\Visual Studio Projects\Shop Floor Control\BusinessModel\WesteelConfigReader.vb:line 8

       at Westeel.ProductionSchedule.Scheduler.ScheduleOrder(BillOfMaterials bomParent)

       at Westeel.ProductionSchedule.Scheduler.ScheduleOutstandingOrders(String siteId)

    The action that failed was:

    Demand

    The type of the first permission that failed was:

    System.Security.Permissions.FileIOPermission

    The first permission that failed was:

    <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

    version="1"

    PathDiscovery="c:\windows\system32\inetsrv\WesteelConfig.xml"/>

     

    The demand was for:

    <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

    version="1"

    PathDiscovery="c:\windows\system32\inetsrv\WesteelConfig.xml"/>

     

    The granted set of the failing assembly was:

    <PermissionSet class="System.Security.PermissionSet"

    version="1">

    <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

    version="1"

    Flags="Execution"/>

    <IPermission class="System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

    version="1"

    PublicKeyBlob="002400000480000094000000060200000024000052534131000400000100010053F5BE9FF6E27CC3D78494864AF72EE770628BC97E5DF9224D4B745B868407FE7DEC57AE6BF18407D0ACC6E140FF26C54C8985796A3118F828CD5AD22F22D019192E03CDCC26E1FEBAFC7FEFBE1697252C0BEF1F631B146FEDA71E0D421FAF8FAE00CE813CAA2254A1799819F266975FAD2B14D6687540EEC19405753ED4BBB7"

    Name="BusinessModel"

    AssemblyVersion="1.0.0.0"/>

    <IPermission class="System.Security.Permissions.UrlIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

    version="1"

    Url="file:///C:/inetpub/wwwroot/WesteelERP/bin/BusinessModel.DLL"/>

    <IPermission class="System.Security.Permissions.ZoneIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

    version="1"

    Zone="MyComputer"/>

    <IPermission class="System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

    version="1"

    Level="Minimal"/>

    <IPermission class="Microsoft.SharePoint.Security.WebPartPermission, Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

    version="1"

    Connections="True"/>

    </PermissionSet>

     

    The assembly or AppDomain that failed was:

    BusinessModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=87434fb0838317d2

    The method that caused the failure was:

    System.String ReadSetting(System.String)

    The Zone of the assembly that failed was:

    MyComputer

    The Url of the assembly that failed was:

    file:///C:/inetpub/wwwroot/WesteelERP/bin/BusinessModel.DLL

    Monday, June 05, 2006 4:27 PM

Answers

  • I found the solution with the help of MS support.  My assembly should have had unrestricted permissions, however since I had Sharepoint running on the same computer Sharepoint basically overrides the security for all websites and sets it to a very restricted set of permissions.  To fix it I added this line to my Web.Config for the web service:

    <trust level="Full" originUrl="" />

    Thursday, June 08, 2006 1:24 PM
  • I had a similar problem with permissions with that error.

    Check this article out:

    http://www.15seconds.com/issue/040121.htm
    Wednesday, December 06, 2006 9:41 PM

All replies

  • The easiest way to deal with File permission problems is to use NtFilemon
    to track the file. First start it up and right click and exclude process on stuff that you don't need such as explorer.exe, crss.exe etc. Once you've got most of the stuff filtered out clear the buffer and then run the offending code. When the offending code is run and the file permission is thrown there should be an Access Denied entry. Search for Denied and when you find it scroll over to the right. It will show you which user was trying to access the file.

    Hope this helps.
    Monday, June 05, 2006 4:51 PM
  • I will definately give that a shot.  But the nature of the error message leads me to believe that it is not Windows security (ie. the file's ACL), but Code Access Security in .Net that is saying that this code is not secure enough (based on its location, source, etc) to be able to access this file.  I would expect that if it was due to the windows access permissions on the file the error message would be quite different.

    I am also using Impersonation in my Web Service, and it is running under my user account which has Admin on the web server box.

    Monday, June 05, 2006 6:38 PM
  • Are you accessing a file that is remote or came from a remote source? I'd still run the ntfilemon just to rule everything out? If it's coming from a remote source you may need to set up  a special trust with the .NET Configuration wizard in the administration panel.
    Monday, June 05, 2006 6:46 PM
  • The XML file was deployed along with the web service (part of the msi).  I also manually copied it to the C:\Windows\System32\inetsrv\ directory since for some reason that seems to be where my DLL is trying to open it from (that's a different issue that I'm sure I can fix easily enough when I get some time).

    I tried running the FileMon and the request to read that file never showed up in the utility.  So it doesn't appear to be making it past the CLR.

    Somthing that may or may not help troubleshoot this, is in the Web Service code (not the DLL) I have some code that is writing to another txt file in the same directory that succeeds with no problems (it shows up in FileMon as SUCCESS). But when I try to read from the XML file in the same directory from my DLL it throws the security exception.

    The code in the DLL attempts to access the file using this code:

    Dim MyReader As System.Xml.XmlTextReader = New System.Xml.XmlTextReader("WesteelConfig.xml")

    The code in the Web Service attempts to access the file using this code:

    Private Shared ShopFloorFileWriter As IO.StreamWriter = My.Computer.FileSystem.OpenTextFileWriter("ShopFloorLog.txt", False)

    Any idea what next step I can take to troubleshoot this issue?

    Monday, June 05, 2006 7:23 PM
  • FileIOPermission fp = new FileIOPermission( FileIOPermissionAccess.Read, PathGoesHere );           
    PermissionSet ps = new PermissionSet(PermissionState.None);            
    ps.AddPermission( fp );
    XmlTextReader reader = new XmlTextReader(@"c:\temp\tmp.xml");
    reader.XmlResolver = new XmlSecureResolver(new XmlUrlResolver(), ps);

    The above code should hopefully solve the problem. if not You will need to decrease the security for your hosted application or grant it FileIOPermission.
    Wednesday, June 07, 2006 1:14 PM
  • I found the solution with the help of MS support.  My assembly should have had unrestricted permissions, however since I had Sharepoint running on the same computer Sharepoint basically overrides the security for all websites and sets it to a very restricted set of permissions.  To fix it I added this line to my Web.Config for the web service:

    <trust level="Full" originUrl="" />

    Thursday, June 08, 2006 1:24 PM
  • I had a similar problem with permissions with that error.

    Check this article out:

    http://www.15seconds.com/issue/040121.htm
    Wednesday, December 06, 2006 9:41 PM
  • I have a similar problem, but my application is an XAML Browser Application (WPF, Silverlight) that is hosting the .dll

     

    There is no web.config to set the trust.

     

    However, there is an app.manifest, shown below.   How can I apply full trust permissions so that the .dll I call can access a resource (OLAP database in my case) across the intranet?

     

     

    <?xml version="1.0" encoding="utf-8"?>

    <asmv1:assembly manifestVersion="1.0" xmlns="urnTongue Tiedchemas-microsoft-com:asm.v1" xmlns:asmv1="urnTongue Tiedchemas-microsoft-com:asm.v1" xmlns:asmv2="urnTongue Tiedchemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <trustInfo xmlns="urnTongue Tiedchemas-microsoft-com:asm.v2">

    <security>

    <applicationRequestMinimum>

    <defaultAssemblyRequest permissionSetReference="Custom" />

    <PermissionSet class="System.Security.PermissionSet" version="1" ID="Custom" SameSite="site" />

    </applicationRequestMinimum>

    </security>

    </trustInfo>

    </asmv1:assembly>

    Monday, March 03, 2008 5:09 PM
  •  

    Well, I solved this by going into the Security tab and selecting the suggested radio button "This is a full trust application".  However it does cause me deployment grief (which I discuss in another thread).

     

    Thursday, March 06, 2008 8:03 PM
  •  John Bailo wrote:

    However it does cause me deployment grief (which I discuss in another thread).

     

    John, please post a link to the other thread, for those who find this one in the future.

    Friday, March 07, 2008 12:51 AM
  •  John Saunders wrote:
     John Bailo wrote:

    However it does cause me deployment grief (which I discuss in another thread).

     

    John, please post a link to the other thread, for those who find this one in the future.

     

    Here is the new (ongoing) thread.

     

    XBAP Deployment via Browser Fails -- Full Trust Not Granted
    http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2963131&SiteID=1

     

    Summarizing:


    There seems to be a trade off in ease of use of XBAP deployment and being able to grant all the permissions necessary for a complete application.

    Friday, March 07, 2008 3:54 PM
  • Deployment grief!! That's an understatement. The whole concept of Code Access Security is a large pain-in-the-neck that takes away from the ease of development that comes with .Net. The concept of Click-Once is trivial and those of use in the software business who have to run with thick clients (like the entire Microsoft Dynamics suite of products) that run from a share.

    It's a real pain to implement when the programs we sell run on 98% of the computers but th 2% have the damn CAS security exception problems that dectuple the implementation time.
    Price Brattin, SQLServer MCP, Microsoft Dynamics SL Consultant
    Monday, June 02, 2008 9:43 PM
  • I'm not sure how many would agree with you that security is a bad thing. If you want to find out how many that is, then I suggest you create a Connect article about it, and see how many votes you get.
    John Saunders
    Tuesday, June 03, 2008 12:12 AM
  • Security is not a bad thing. But the way security is implemented and setup in the framework is a bad thing. The various options are too granuar and difficult to understand. CasPol.exe is a rinky-dink DOS-like program with cryptic, esoteric commands. Probably ClickOnce was designed to make up for the shortcomings of CasPol.exe but it fails miserably for any app other than the trivial designed to work without a managed server. ClickOnce was not designed for the enterprise with numerous servers and hundreds of clients. Getting Framework security to work correctly is a nightmare for the large IT shop. And judging from the comments above it is a pain for the developers too.


    Price Brattin, SQLServer MCP, Microsoft Dynamics SL Consultant
    Tuesday, June 03, 2008 3:19 AM
  • This sounds very much like you've thought this through. Please give Microsoft and the rest of us the benefit of your reasoning by creating a Connect article. They really do read them.

    Also, post a link to the Connect article as a reply here. This is one of the most-read threads on the Forum. Many people may read your Connect article, and if they agree with you, vote for it. That helps Microsoft prioritize.

    You can help us all by creating that article.

    John Saunders
    Tuesday, June 03, 2008 12:04 PM