What parts of .NET require administrative priviliges to be executed?

Question

Which parts of the framework require a user to be more than a Standard User? The reason I'm asking is because I'm trying to compile a list of possible issues with our existing applications when migrating to Windows 7.

Now, I can think of a few things myself:

• Writing to Eventlog
• Writing to Registry Keys outside of Current_User scope
• Getting an Environment variable
• etc...

I really would like a more complete list and so far I've not come across a decent resource in which all this stuff is listed.

Note that I'm not looking for ways of elevating the priviliges for the existing apps (which can be done by using a manifest), I'm simply idenitifying actions in code that might cause issues.

Answer 1

Well, your examples don't really have anything to do with Windows 7 or .NET. Actually they were already part of the "Designed for Windows NT 4.0" logo requirements. If you have written your application in a way that non-admin users were able to run it on NT, Win2k or XP, it will just work fine on Vista/Win7.

There is another common pitfall when you run your software on x64 systems (however this too isn't specific to Win7 but is true e. g. for Win2003 Server x64 or Win XP x64 as well): If you are working with native 32-bit code, like calls to a native DLL or COM interop with a in-process component), make sure to select "x86" as the platform target in Visual Studio project settings instead of "Any CPU". Otherwise your application will run as a 64 bit process, and you can't mix 32 and 64 bit code in the same process, so you would run into errors.

And of course, as it always has been best practice, use Environment.GetSpecialFolders instead of hard-coded paths.

Answer 2

One place to get a partial list is to look in the "Local Group Policy Editor" where you can check what Logon rights and Privileges are only assigned to administrators by default.

Answer 3

Thinking of it as "What library calls" is going to lead you down the wrong path. Think about anything that writes to a file. If that file is under Program Files (among other places), you need admin privs. If it's under AppData, you don't. Same library call, different outcomes. Ditto for writing to the registry - HKLM you need admin, HKCU you don't. Writing to Event Log is generally ok but creating your event source is not. And so on. It's not about what method you call, it's more about the params (eg path) you pass to it.

Answer 4

Named Pipes can cause issues. Normally this isn't an issue, but use of Named Pipes is now increasing with WCF supporting them natively for IPC transport.

Answer 5

I don't believe getting environment variables need elevating privledges. At least I've never run into it, are there really cases where that's true?

Answer 6

Nothing in .Net framework requires administrative privileges. Everything that has to do with user-level security is controlled by the OS, and whether admin privileges are required is a matter of OS configuration. Thus, the framework can't make the determination whether it needs to require elevation.

You should be thinking not in terms of "What in the .Net framework requires elevation?", but in terms of "What OS features is my app using that require admin elevation in the default configuration". And as @Marcus said, "Designed for Windows NT 4.0" logo requirements is a very good starting point to determine which OS features your app should be avoiding if it's designed to run as regular user.

Answer 7

You can use the Luapriv checks from the Application Verifier to help you find issues. Also the Standard User Analyzer will help you.

Answer 8

If I'm understanding your question correctly, Visual Studio can calculate this for you...

Just go to your project's properties, click on Security tab and check "Enable ClickOnce Security Settings" checkbox. Select "This is a partial trust application" radio button and then click on "Calculate Permissions" button.

VS will place a checkmark next to each permission like IO, Registry, etc your application requires...

Answer 9

I seriously doubt there is a way to get a complete list of .NET calls that require elevation of privileges.

BTW writing to the Event Log doesn't require elevation, however creating an Event Log source does require elevation.

The best way to find out which parts of your code have issues is by testing on Win7 and see what breaks, not elegant but does the job. If you are looking to create time estimates for this task, then you might have to spend a day or two hacking through your app: run on Win7, see what breaks, make note of it, comment/avoid/disable that section, and repeat until you think you have enough a of list of things to address.