When you encounter security issues, is your first inclination to enable Full Control on the everyone account? I certainly hope not, and if it is, you won’t be developing software for very long. Maybe you should be campaigning for Student Council president: “Chocolate Milk for Everyone!” If you struggle with knowing which account is accessing which resource, check out FileMon from SysInternals (www.SysInternals.com). It’s free. It’s powerful. I should point out that virtual buddy Brendan Tompkins (a virtual buddy is one you’ve never met face-to-face) blogged about another SysInternals tool here.
FileMon (and many other tools from SysInternals) has been around for a long time, but since many of my student’s haven’t been around software development or at least .Net for a long time, I feel obliged to share this FileMon story with you.
Many web applications require some sort of writing to the file system (log files, uploaded documents or images, etc). The app I’m working on generates some report graphics that need to be saved on the sever (in case you were concerned about server disk space management, they get erased once they’ve aged over 1 day; creating them in memory is not an option in this case). My first attempts to write to the server file system failed, returning a generic “Error in GDI+” message; .Net graphics handling is great, but the error messages can be a bit vague.
Instinctively, I suspected a permission issue so I checked out the security on the folder I was writing to. Besides the default system permissions, the folder had Modify permissions for the Domain\ASPNet account and the Machine\IUSR_MachineName account. It looked ok at first glance. When I gave Everyone Full Control to the folder (just as a test!), the application wrote the files out without any problem — so this was certainly a permission issue. I cleaned up my “Full Control” test with the Everyone account; that’s an unacceptable work around, even for a dev box!
What to do? I could start experimenting with Impersonation via web.config, or try any number of other things, but I decided to fire up FileMon.exe to get a look at what’s going on. FileMon, as the name suggests, monitors the file system and tracks file activity. You can download it from www.SysInternals.com (in the utilities section — here).
FileMon generates a lot of output (amazing how many requests the OS and other services generate), so only start it up right before you being the activity you’re investigating. I started FileMon, went to the File Menu, and unchecked the Capture Events option (this stops FileMon from tracking activity). Then I went to the Edit Menu and clicked on Clear Display to give me a blank log to work with. I started my web app, and right before clicking the button that generated my exception, I toggled over to FileMon and rechecked the Capture Events option to start the monitoring session. I clicked my button and waited patiently for the exception to be raised — FileMon will slow your apps down a good bit.
Once my exception was displayed on the screen, I unchecked the Capture Events option in FileMon; I didn’t want FileMon to keep tracking activity while I reviewed the log. I had over 100 entries already!
Starting at the end of the log, I reviewed each entry, looking for a “Failure” in the Result column. I quickly found my failed request, and the Path column displayed the folder my web app was writing to. In the Other column was the account that was requesting permission to the folder . . . this was it . . . to my chagrin, Machine\ASPNet was displayed. I realized then that the Domain\ASPNet account was configured for the folder INSTEAD OF Machine\ASPNet. I quickly gave Machine\ASPNet write and modify permissions to the folder and my web application was off and running fine again.
FileMon made this oversight easy to identify, and saved me -potentially- lots of wasted time. It took me only a few minutes to diagnose and resolve the issue.