Geeks With Blogs
Blog Moved to http://podwysocki.codebetter.com/ Blog Moved to http://podwysocki.codebetter.com/
Recently on a project, I was bit hard by a Least User Access (LUA) bug that I ultimately should have caught.  I was using a third-party component which was performing some unexpected operations.  I didn't catch this item, however, until it almost went live.  And it was intermittent at best when it failed.  This was an unknown unknown as opposed to one of those known unknowns.  So, where did my process go wrong?

LUA and Development

Going back through my career, I've usually been security focused.  I want my applications to have the smallest security footprint as possible.  This includes all service accounts being general users for such things as SQL Server, SharePoint, BizTalk, and IIS application pools. 

In the past, Visual Studio was very picky about running as a general user which has precluded many from doing so.  Things that were very picky was the ability to debug among other things.  I'm just as guilty as the rest because I want to get it done and I want it now.

Unit Tests or Integration Tests?

When I wrote my unit tests, because I wasn't validating user access, security was not something on my mind for writing tests on.  So, security fell by the wayside here.  I wasn't concerned with impersonation as a service account as I felt it was more of an integration test issue.  If I were checking if a user had access to a particular resource, then writing unit tests would be in the forefront to check for all forks in the code.

So, this fell into an integration test, end to end.  Once again, since it was an intermittent problem, I didn't catch it there either.  I was ok with my resources and tests was busy running its course.  But, what I forgot to do here was impersonate a service level account.  My resources had the proper account privileges such as SQL Server, but the overall in-process calls were that of an interactive user and not a service level account.  Hence why this bug wasn't caught.

So, instead, I had to sit there with Process Monitor from SysInternals (an invaluable tool) and poured over 9,000 events to look for any access denied errors.  It wasn't a fun evening to say the least, but it should have been caught earlier.  It's really time to break out my Michael Howard books again on the subject. 

Conclusion

This was an important lesson and a hard one to learn.  Even though the behavior of my third-party component was undocumented, it should have been caught earlier in the process.  It was a good learning experience for me and enforced LUA principles.  It also has strengthened the fact that unit tests prevent a lot of mistakes, but ultimately, when I need to glue it all together, integration tests are just as important.  Anyone else have similar stories?

It's a continuing learning experience and it never gets old...

kick it on DotNetKicks.com Posted on Friday, January 25, 2008 4:59 PM Test Driven Development | Back to top


Comments on this post: Adventures in TDD - Bit by the LUA bug

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Matthew Podwysocki | Powered by: GeeksWithBlogs.net