Lesson Learnt: Building & Running Application as Non Admin
Wow, it's been awhile since I add an entry to this blog. Been busy at work.
I was contacted by one of my friends a couple days back.
"I have a problem, " he said. "I have a smart client application that is storing its settings in the Windows Registry. It was working fine when we tested it, but when the client deployed it to the users, the application blew up since it could not update its setting in the registry. We tried HKLM and HKCU but it just would not work." He then realized that the client's company is enforcing a lock down policy in where no client will have write access to the Windows Registry unless they belong to the Administrator group.
Yesterday, I was talking to my co-worker about an OpenXML reporting framework that we built for one of our projects. I found out that he was saving the resulting OpenXML Word document file in the directory where the program is installed. So, there is nothing wrong with this scenario, right?
From the examples above I'll make the following assumption:
- During the testing period, my friend was developing and testing his application as a local administrator on the development and test machine.
- My co-worker assumed that it is okay to have the application write to the C:\Program Files (regular installation path) since he was able to do it as a developer (also developing as local administrator on his development machine).
These two cases reminds me when I was trying to harden up the security on my laptop (running Vista with UAC turned on). My goal was that no other user except myself (well, actually including my own account since UAC is turned on) should be able to write anything other than to his/her own profile folders (My Document, AppData, etc.). So if someone was able to login as guest on my laptop, all he / she can do is store documents and files in their own profile folders and nowhere else. No application install, nothing.
I imagine this is what happened in example 1 above. It might screw up example 2 application if similar policy is being enforced in the workplace.
So...
"Where should we store our modify-able settings?" you asked.
As I hinted above, I think you should really make use of the profile folders. In my opinion, it is the right place to put all these stuffs, especially when we finally move on to Vista environment with UAC turned on. The profile folders should be read and write-able for all users by default. Unless the domain administrator is a control freak, well...
So, how do you do this in .NET? Thankfully, .NET Framework already provides us with System.Environment class that will enable you to do just that. Take a look at the following code:
string appData = Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData);
// .NET 1.1 flavor
string myDoc = Environment.GetFolderPath(Environment.SpecialFolder.Personal);
//.NET 2+ flavor
string myDoc = Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments);
Again, this is just my thought. It might not be 100% correct. If it is not, or if you have a better idea on how to solve this problem, please let me know.
After browsing around a little more regarding this topic, I also came to this particular article in Microsoft Technet regarding Vista UAC. This might shade some more light on this particular topic where Vista is concerned.
Call to action: Code and test using a non-administrator account whenever possible. You'll catch more security related bug that way before it can reach the real user.
Have fun coding!!