I've been working on a small program for my gaming laptop to change the resolution setting of games to match the desktop resolution. The main reason for this is due to my differing play enviornments of 1280x720, 1280x800 and 1280x1024. Some games force a relaunch of the game to change the resolution, and this can get annoyning especially with MMOs that force you to properly "camp" to exit the game. I settled on C# since I figured it would be a good language to learn to make some tiny windows programs in with my knowledge of C. Plus it gives me some insight into how Objective C works so I can do similar programming on my Mac.

Anyhow, I got the program to a point where it can change 4 games on the system. And because I wanted to distribute this to a friend with a similar setup, I coded the game detection to read registry values to find where the game is installed. Before I sent it to him, I put the program on my home server, and tried it out on a different Windows box in my house. And I stumbled on an bug doing this. Oddly, reading the registry only works if the program is running on the local hard drive. If it is on a network share (\\share\name or a mapped drive), the exception handling I have in it spits back with this exception basically complaining about registry permission issues.

Now for the rant.

Aparently, to prevent that exception, I need to put in a call to RegistryPermission into my program to request access to the registry. I can understand some reasons for this, but why label it security? As stated above, none of this is needed when it runs on the local hard drive. And the fact that I can simply ask for read/write access to the entire registry without the system balking, well, seems to be not so secure. So all this fuction really does is add work to the programmers.

Maybe I'm missing the point of this process, but for now it has given me an interesting look at Microsoft "security" practices. It really does explain why MS apps have major security issues, even after their initiatives to make secure products like Server 2003 and XP SP2. The good unanswered question is why thousands of programmers at Microsoft are missing such glaring holes not only in their code, but in the APIs they write to make the code.

> And I stumbled on an bug doing this. Oddly, reading the registry only works if the program is running on the local hard drive. If it is on a network share (\\share\name or a mapped drive), the exception handling I have in it spits back with this exception basically complaining about registry permission issues.

I don't think that is a bug, it is by design. I admit my knowledge of .Net security is rather lacking (so much to learn, the .Net framework is enormous) but I do know that security really cramps your style when running things over the network.

Have you actually succeded in writing to the registry from a program running over the network? My understanding is that RegistryPermission won't do squat by itself, and the local machine still has to have its security setting set up to allow it.