none
Application dll load failure with Access Denied though the user has 'full control' permission

    問題

  • I have an application where in a process(say X.exe) is spawned remotely in another machine. X.exe is spawned in the remote machine's administrator user context. But it terminates without executing. I monitored this using ProcessMonitor and found that X.exe is doing a CreateFile on a dll. This call is failing with Access Denied and the application does not come up. The exe and the dll are situated in the Program Files folder. I verified that the Administrator user has "full control" permissions on the folder where the exe is placed.

    I am not able to find the reason why there is an Access Denied while the executing user has all the permissions.

    Any help on this is much appreciated.

    Thanks.

    2012年3月5日 下午 01:19

解答

  • Found out something interesting. The permissions for the group Network are all denied. I tried modifying this to "Read and execute" on the dll and it started loading the dll.

    It makes sense that it is launched in the context of that security grouping as a remotely started process. It is best practice to never modify the permissions of any of the built in security groups (not sure you meant you where doing that, but best to have it stated). Each group is designed with a security purpose and intent.

    The process is created as Administrator using CreateProcessAsUser whose credentials are passed over the Network. So does this take the permissions for the 'Network' group instead of those for the Administrator?

    From what platform is CreateProcessAsUser being called? If your make this call from something running in the context of an IIS Application pool then by default the context is set to NetworkService. Therefore this will likely be be the context received when the CreateProcessAsUser is called (regardless of the user specified). You can change the context of an application pool to a custom security context using the inetmgr tool.

    If your launching from a COM or COM+ component set the "Activate and Launch" permissions appropriately using the dcomcnfg MMC snap-in to the correct custom user account (never assign any COM or COM+ to a built in account).

    If your making a direct attempt to launch a remote process (not recommended), ensure that all the required remote administration ports are open and accessible and that the two machines have trust relations established / share the same active directory.

    Sorry I'm not able to give you a more direct answer, but I'm having to narrow down the domain of failure. Hopefully these comments will provide you with some directions.


    Kind Regards, V Website: http://www.kvkconsultancy.co.uk

    2012年3月7日 下午 02:54

所有回覆

  • Have you verified that this process is spawning with administrator access? Also, what permissions does the user have on the DLL itself.


    This is a signature

    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Do you want Visual Studio 11 Express to be freely installable on Windows 7 and able to write regular C++ applications? Please vote for this.

    2012年3月5日 下午 05:28
  • You need to find out a bit more than simply 'X.exe is doing a CreateFile on a dll'.

    CreateFile is used for both creating new files and (confusingly) opening existing files, and it also needs to handle the sharing of the file with other processes using it at the time.

    Also, you should check the permissions on the file itself (as distinct from the permissions on the folder it is in).


    Answering policy: see profile.

    2012年3月5日 下午 06:12
  • I see that the process is running under the Administrator account (Process monitor's user information shows that). Doesnt that provide the process administrator access? Or is there a way I should determine whether the process is spawned with administrator access?

    Thanks

    2012年3月6日 上午 05:11
  • The permissions for the Administrator is the same on the folder and the dll. In this context, the CreateFile is used to implicitly link a dll to the exe while the application loads.

    Thanks

    2012年3月6日 上午 05:13
  • I can think of many reasons any remote process may fail:

    Firstly, what Session has the remote process spawned in? Any session appart from the users interactive session may cause limitations and lead to access being denied.

    Secondly, have you been granted and enabled the priviledges you may require in the remote process?

    Thirdly, are you running at a sufficiently high integrety level?

    Forthly, has the process been virtualized? Do you have the necessary permissions in the virtualized locations as well at the real locations.

    When you say "terminates without executing" it appears a contradiction? I am guessing you mean it loads the image into memory but does not call the WinMain (Is there is some intermediary like and Anti-Virus etc).

    How is the remote executable being spawned? Does the spawing process have sufficient permissions, does it pass on those permissions on when it spawns your process? (remember a process can spawn another process logged on as administrator but running with very very limited permissions)

    So theres a list of things to consider. One way a exe image can be loaded into memory and not be executable is if its loaded as a resource.


    Kind Regards, V Website: http://www.kvkconsultancy.co.uk

    2012年3月6日 下午 11:36
  • Found out something interesting. The permissions for the group Network are all denied. I tried modifying this to "Read and execute" on the dll and it started loading the dll.

    The process is created as Administrator using CreateProcessAsUser whose credentials are passed over the Network. So does this take the permissions for the 'Network' group instead of those for the Administrator? From the behaviour, it seems to be so.

    2012年3月7日 上午 10:33
  • Found out something interesting. The permissions for the group Network are all denied. I tried modifying this to "Read and execute" on the dll and it started loading the dll.

    It makes sense that it is launched in the context of that security grouping as a remotely started process. It is best practice to never modify the permissions of any of the built in security groups (not sure you meant you where doing that, but best to have it stated). Each group is designed with a security purpose and intent.

    The process is created as Administrator using CreateProcessAsUser whose credentials are passed over the Network. So does this take the permissions for the 'Network' group instead of those for the Administrator?

    From what platform is CreateProcessAsUser being called? If your make this call from something running in the context of an IIS Application pool then by default the context is set to NetworkService. Therefore this will likely be be the context received when the CreateProcessAsUser is called (regardless of the user specified). You can change the context of an application pool to a custom security context using the inetmgr tool.

    If your launching from a COM or COM+ component set the "Activate and Launch" permissions appropriately using the dcomcnfg MMC snap-in to the correct custom user account (never assign any COM or COM+ to a built in account).

    If your making a direct attempt to launch a remote process (not recommended), ensure that all the required remote administration ports are open and accessible and that the two machines have trust relations established / share the same active directory.

    Sorry I'm not able to give you a more direct answer, but I'm having to narrow down the domain of failure. Hopefully these comments will provide you with some directions.


    Kind Regards, V Website: http://www.kvkconsultancy.co.uk

    2012年3月7日 下午 02:54