ACL Hell

In my last post I discussed the potentials for System.Diagnostics.Process in a solution implementation we were facing.

In this post I'm not ashamed to admit that I probably went down the wrong path with my System.Diagnostics solution, what I found was, when I attempted to get the diagnostics information from a process through our IIS hosted application, the application didn't have the sufficient access rights to get to the service processes that were running in the system account.

My development was code complete, I merged it with our testing environment branch only to find that the application wasn't returning the process list I was expecting but only a small number of processes that ran at the same access level as my IIS.

I tend to turn ACL off on my local machine as it really annoys me, however, in this case, I made the mistake of not doing early testing on the remote Development environment and checking the impact of the User Account Settings.

At this point i hoped to find a quick fix rather than attempt a complete re-implementation.

I asked the question on Stack Overflow and MSDN Forums.

Both responses weren't what I really wanted to hear, but it was back to the drawing board for me...

I made the decision to create a windows service host that could call a simple ServiceStack service implementation, the beauty being this service would be running at the same access rights as the ones that I wanted to provide diagnostics for.

After some re-factoring and a little new code, I've implemented a solution that works just great. Our Pingdom account calls our web application, the web application calls the SerivceStack service through the client and the SerivceStack service returns all the process information we need for any given service.

I did encounter some late issues around trying to return the System.Diagnostics.Process type as an array, as mentioned in the MSDN response, you can't actually access all of the properties of a process using Sytem.Diagnostics.Process at all times.

When the ServiceStack implementation tried to serialize the data from the process object some exceptions were occurring on properties that can only be accessed when the process has been exited.

The attempted serialization would have invoked a call to the ExitTime Property which defines the moment when the process died. As the process is still running it caused the application to throw a System.InvalidOperationException: "Process must exit before requested information can be determined."

This resulted in me wrapping the .net System.Diagnostics.Process class information with my own lightweight implementation, which did three things, it fixed my error, reduced the information I was returning to the exact information I need currently and finally removed a code smell that stopped me from being able to unit test my code.

Once I implemented my own wrapper with an interface I could mock out the return rather than depending on the Diagnotics.Process class itself which provides a collection of read only properties.

I need to refactor the code out of the final implementation, however, I still think this could be a fun project to work on and fully intent to provide a GitHub solution in the coming weeks.

1 comment:

  1. Amazing! This is the extremely lovely property that I at any point saw. I looked it on the web and see photos of this town but you can get essay services reviews to manage your educational task. This town is normally excellent. There are numerous things for visiting, a lake is likewise here that additional four stars in his magnificence.