Running .NET applications on Vista without admin privileges [modified]
-
I was going to ask this in the Vista forum but that appeared to refer more to the Vista win API than to how the .NET framework runs on Vista, so I'm asking here.. Maybe my Google-fu sucks, but I can't seem to find any pointers on how to write applications to ensure they'll run on Vista without elevated privileges. In particular, I'm interested in the following things that will trigger the elevated permissions system: * Which P/Invoke functions to avoid * Which .NET namespaces to avoid (the Cryptography namespace forces elevated privileges?!?!?!?!?!?!) * Which files and directories to avoid (I know, \Program Files\ and %WINDIR%\system. Any others?) Also, a bonus would be some kind of tool that will tell me specifically which of these areas will cause Vista to refuse to run my application. I found this tool[^], but all that does is report errors from the low-level operating system API that mean very little to me. Fundamentally my issue is that I'm writing an application that RUNS fine on XP, INSTALLS fine on Vista using a VS2005 setup project, (but it DOES request elevated permissions), but it will not RUN on Vista (UAC does ask to allow the program to run). And even when the user selects ALLOW, the program still crashes. For the life of me I can't seem to pinpoint why. The best I seem to be able to find are recommendations of embedding a manifest file to demand admin privileges. Well, that isn't what I want to do. I want my application to run under normal user permissions, but I can't figure out WHAT in my application is triggering the request to elevated privileges. Pointers are appreciated... this is pretty aggravating.
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
modified on Monday, January 07, 2008 4:03:11 PM
-
I was going to ask this in the Vista forum but that appeared to refer more to the Vista win API than to how the .NET framework runs on Vista, so I'm asking here.. Maybe my Google-fu sucks, but I can't seem to find any pointers on how to write applications to ensure they'll run on Vista without elevated privileges. In particular, I'm interested in the following things that will trigger the elevated permissions system: * Which P/Invoke functions to avoid * Which .NET namespaces to avoid (the Cryptography namespace forces elevated privileges?!?!?!?!?!?!) * Which files and directories to avoid (I know, \Program Files\ and %WINDIR%\system. Any others?) Also, a bonus would be some kind of tool that will tell me specifically which of these areas will cause Vista to refuse to run my application. I found this tool[^], but all that does is report errors from the low-level operating system API that mean very little to me. Fundamentally my issue is that I'm writing an application that RUNS fine on XP, INSTALLS fine on Vista using a VS2005 setup project, (but it DOES request elevated permissions), but it will not RUN on Vista (UAC does ask to allow the program to run). And even when the user selects ALLOW, the program still crashes. For the life of me I can't seem to pinpoint why. The best I seem to be able to find are recommendations of embedding a manifest file to demand admin privileges. Well, that isn't what I want to do. I want my application to run under normal user permissions, but I can't figure out WHAT in my application is triggering the request to elevated privileges. Pointers are appreciated... this is pretty aggravating.
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
modified on Monday, January 07, 2008 4:03:11 PM
Maybe some help here... Windows Vista Application Development Requirements for User Account Control Compatibility[^] Good luck and please let us know what you find! Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Maybe some help here... Windows Vista Application Development Requirements for User Account Control Compatibility[^] Good luck and please let us know what you find! Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Thanks Mark, I'll take a look. I also found a 30-day eval Vista virtual hard drive, so I will do some testing.
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
-
I was going to ask this in the Vista forum but that appeared to refer more to the Vista win API than to how the .NET framework runs on Vista, so I'm asking here.. Maybe my Google-fu sucks, but I can't seem to find any pointers on how to write applications to ensure they'll run on Vista without elevated privileges. In particular, I'm interested in the following things that will trigger the elevated permissions system: * Which P/Invoke functions to avoid * Which .NET namespaces to avoid (the Cryptography namespace forces elevated privileges?!?!?!?!?!?!) * Which files and directories to avoid (I know, \Program Files\ and %WINDIR%\system. Any others?) Also, a bonus would be some kind of tool that will tell me specifically which of these areas will cause Vista to refuse to run my application. I found this tool[^], but all that does is report errors from the low-level operating system API that mean very little to me. Fundamentally my issue is that I'm writing an application that RUNS fine on XP, INSTALLS fine on Vista using a VS2005 setup project, (but it DOES request elevated permissions), but it will not RUN on Vista (UAC does ask to allow the program to run). And even when the user selects ALLOW, the program still crashes. For the life of me I can't seem to pinpoint why. The best I seem to be able to find are recommendations of embedding a manifest file to demand admin privileges. Well, that isn't what I want to do. I want my application to run under normal user permissions, but I can't figure out WHAT in my application is triggering the request to elevated privileges. Pointers are appreciated... this is pretty aggravating.
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
modified on Monday, January 07, 2008 4:03:11 PM
Don't think of what to avoid, think of what the minimum you should do is. It's safe to write to the user's profile. That's pretty much it. Anything that changes the system configuration is likely to fail for a standard/non-elevated user. No APIs force elevated privileges. UAC will automatically apply elevation if it thinks that you're a legacy setup program (if your program name or resources contain the words 'setup' or 'install') or if there's a compatibility shim detecting the program that requires it to run elevated. Otherwise, your program does not prompt, and runs in a 'virtualized' environment, where writes to certain registry keys and protected disk locations are redirected to shadow folders under the user profile. A manifest is necessary to tell Windows Vista that you are aware of the presence of UAC. If you never want it to prompt, set the
requestedExecutionLeveltoasInvoker. This means 'never ask for administrative rights even if the user is an admin'. The other available settings arerequireAdministrator, which always prompts (for confirmation for administrators, for admin credentials for non-admins), andhighestAvailable, which prompts administrators for confirmation but runs without admin privileges, without prompting, for non-administrators. The latter is a bit of a compromise and you're recommended to strip the administrative functions out into a separate program. As soon as you install a manifest containing one of these settings, Windows Vista will disable the legacy redirection. You'll then get exceptions as appropriate as you use APIs for which you don't have permission. Another simple way to test is to run your program under Windows XP as a standard user. That'll blow up all over the place. The Windows security model is so much more sophisticated than a simple admins can/non-admins can't system. Most of Windows security is based on Access Control Lists, which define exactly what different security principals (users or groups) can or can't do. In addition there are a separate set of privileges which are again assigned to users or groups; these privileges largely allow you to override the ACLs (for example, the ability to change the ACL is normally a permission in the ACL, but the owner of the object can overwrite it even if this permission is denied to them in the ACL; administrators also have the right to Take Ownership of the object, then they can write to the ACL).DoEvents: Generating
-
Don't think of what to avoid, think of what the minimum you should do is. It's safe to write to the user's profile. That's pretty much it. Anything that changes the system configuration is likely to fail for a standard/non-elevated user. No APIs force elevated privileges. UAC will automatically apply elevation if it thinks that you're a legacy setup program (if your program name or resources contain the words 'setup' or 'install') or if there's a compatibility shim detecting the program that requires it to run elevated. Otherwise, your program does not prompt, and runs in a 'virtualized' environment, where writes to certain registry keys and protected disk locations are redirected to shadow folders under the user profile. A manifest is necessary to tell Windows Vista that you are aware of the presence of UAC. If you never want it to prompt, set the
requestedExecutionLeveltoasInvoker. This means 'never ask for administrative rights even if the user is an admin'. The other available settings arerequireAdministrator, which always prompts (for confirmation for administrators, for admin credentials for non-admins), andhighestAvailable, which prompts administrators for confirmation but runs without admin privileges, without prompting, for non-administrators. The latter is a bit of a compromise and you're recommended to strip the administrative functions out into a separate program. As soon as you install a manifest containing one of these settings, Windows Vista will disable the legacy redirection. You'll then get exceptions as appropriate as you use APIs for which you don't have permission. Another simple way to test is to run your program under Windows XP as a standard user. That'll blow up all over the place. The Windows security model is so much more sophisticated than a simple admins can/non-admins can't system. Most of Windows security is based on Access Control Lists, which define exactly what different security principals (users or groups) can or can't do. In addition there are a separate set of privileges which are again assigned to users or groups; these privileges largely allow you to override the ACLs (for example, the ability to change the ACL is normally a permission in the ACL, but the owner of the object can overwrite it even if this permission is denied to them in the ACL; administrators also have the right to Take Ownership of the object, then they can write to the ACL).DoEvents: Generating
Mike Dimmick wrote:
Another simple way to test is to run your program under Windows XP as a standard user. That'll blow up all over the place.
Did that.. didn't reveal the issues that came up on Vista though. That said, a manifest both in the installer and in my executable appears to have resolved everything. Incidentally, the installer (the bootstrapper, actually) needs its requestedExecutionLevel set to requireAdministrator in order for installs for Standard Users to work correctly. I'm not sure why that is - if it is set to asInvoker, when the Standard User goes to use the program for the first time and the installer does the shortened install, the files and folders I create in the user's AppData folder don't get created. If the original installer uses requireAdministrator, however, that works just fine. Anyway, thanks for your insight :)
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein