locked
COM Interop Permission Problem RRS feed

  • Question

  • Hi

    I'm trying to wrap up an existing legacy com component in a web service. Below is a simplified example of what I'm trying to do.

    I have created a ActiveX COM DLL project PJoe with a class CJoe which has the following method

    Public Sub test2()

        Dim fn
        fn = FreeFile
        Open "C:\temp\joe.txt" For Output As fn
        Print #fn, "Joe"
        Close #fn

    End Sub

    (This works fine if I call it from a vb project.)

    I then create a .NET web service & reference the PJoe

    [WebMethod]
    public string Test()
    {
     try
     {
    // looking at System.Security.Principal.WindowsIdentity.GetCurrent().Name and User.Identity.Name show that I am running the code under my normal NT login account i.e. not ASPNET or IUSR etc. I'm using <identity impersonate="true" />.

    // the following lines work so I can create a file in c:\temp at this point
      StreamWriter sr = new StreamWriter(@"C:\Temp\Joe.txt");
      sr.WriteLine("Joes");
      sr.Flush();
      sr.Close();

    // however this throws an System.UnauthorizedAccessException with "Path/File access error"
      PJoe.CJoe c = new PJoe.CJoeClass();
      c.test2();
     }
     catch (Exception ex)
     {
      Console.WriteLine(ex.Message);
     }

     return "Test";
    }

    Any ideas what I've missed?

    Thanks

    Joe

    Thursday, September 29, 2005 9:08 AM

Answers

  • It is not that weird.
    What is happening is this. The thread that is running the ASP.NET page is not the
    thread that is running the COM COmponent. You can check this by dumpin the thread ID
    from ASP.NET and the COM coponent it self.
    What is happening here is that the VB COM Component is the Aparatment Threaded component and the ASP.NEt is creating that component in an APARTMENT threaded
    Context. This makes marsahling necessary and the COM COmponent runs in a different thread. This thread does not have the impersonation context. And hence runs in the
    process user context. That explains the whole thing.

    To make your component work, Use C++/ATL and create a component that is
    marked "Both" threaded. 

    Friday, September 30, 2005 5:07 PM
    Moderator

All replies

  • I've got it to work by giving the ASPNET account (?!) write access to the c:\temp directory even though windows impersonate is on, anonymous access disabled & using Integrated Windows Authentication only. The COM Interop appears to use the ASPNET account whereas writing to the same location using the streamreader above uses my own account. Very weird!

    Thursday, September 29, 2005 10:27 AM
  • It is not that weird.
    What is happening is this. The thread that is running the ASP.NET page is not the
    thread that is running the COM COmponent. You can check this by dumpin the thread ID
    from ASP.NET and the COM coponent it self.
    What is happening here is that the VB COM Component is the Aparatment Threaded component and the ASP.NEt is creating that component in an APARTMENT threaded
    Context. This makes marsahling necessary and the COM COmponent runs in a different thread. This thread does not have the impersonation context. And hence runs in the
    process user context. That explains the whole thing.

    To make your component work, Use C++/ATL and create a component that is
    marked "Both" threaded. 

    Friday, September 30, 2005 5:07 PM
    Moderator
  • Thanks for the info & suggestions.

    Joe
    Tuesday, October 4, 2005 2:19 PM