Vista considerations

From ISXKB

(Difference between revisions)
Jump to: navigation, search
(Added some basic info on Best Practices (per-user data etc))
(8 intermediate revisions not shown.)
Line 1: Line 1:
-
Windows Vista now includes a far stricter LUA system. This pretty much stops all applications making system wide changes without asking the user.  (Note that the rules are still the same as they've always been -- but Vista enforces them more strongly.)
+
Windows Vista now includes a far stricter LUA system (LUA = Least-Privilege User Account; not to be confused with the programming language [http://www.lua.org Lua]).
 +
 
 +
This pretty much stops all applications making system wide changes without asking the user.  (Note that the rules are still the same as they've always been -- but Vista enforces them more strongly.)
The recommended minimum version of Inno to use for Vista-capable installs is 5.2.0.
The recommended minimum version of Inno to use for Vista-capable installs is 5.2.0.
 +
For standard-user-only installs, you must use Inno v5.3.7 or later.
== Types of Installer ==
== Types of Installer ==
-
Windows standards recommand two different "classes" of installer:
+
Windows standards recommend two different "classes" of installer:
* '''Administrative'''
* '''Administrative'''
** Runs with admin permissions
** Runs with admin permissions
** Is expected to make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
** Is expected to make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
** ''Should not'' make changes to per-user areas such as HKCU and the current user's profile
** ''Should not'' make changes to per-user areas such as HKCU and the current user's profile
 +
** Should default to installing to {pf}\YourAppName or similar.
** Fully supported by Inno Setup (all versions, although 5.2.0 and above is best under Vista)
** Fully supported by Inno Setup (all versions, although 5.2.0 and above is best under Vista)
* '''Standard user'''
* '''Standard user'''
Line 14: Line 18:
** Is expected to make changes to per-user areas such as HKCU and the current user's profile
** Is expected to make changes to per-user areas such as HKCU and the current user's profile
** ''Must not'' make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
** ''Must not'' make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
-
** Not currently supported by Inno Setup.
+
** Should default to installing to {userpf}\YourAppName or similar.
-
Note that this means that administrative installs ''should not'' install Quick Launch icons, as they are per-user.
+
** Supported by Inno Setup from v5.3.7; limited support on older versions.
 +
Note that this means that administrative installs ''should not'' install Quick Launch icons, as they are per-user. (And of course they have also been deprecated by Microsoft.)
== Inno's Installation Scenarios ==
== Inno's Installation Scenarios ==
-
* '''User is an administrator'''
+
{| border="1" cellpadding="10"
-
** ''PrivilegesRequired has no effect''
+
! rowspan="2" |
-
*** Inno will always present a UAC prompt
+
! colspan="2" |User Type
-
*** You should install per-machine (Administrative install)
+
|-
-
*** You ''can'' do some per-user setup without screwing things up, but it's still not recommended
+
! Administrator !! Standard User
-
* '''User is a standard user'''
+
|-
-
** ''PrivilegesRequired=admin''
+
! align="right" |PrivilegesRequired=admin
-
*** Inno will present a UAC prompt to elevate to an administrative account
+
| Admin Install (Elevation) || Admin Install (Elevation)
-
*** You ''must'' install per-machine (Administrative install)
+
|-
-
*** You ''must not'' do any per-user setup within the install proper (since the user that the setup is running as is not the user who is planning to use the software); see below for more discussion
+
! align="right" |PrivilegesRequired=none
-
** ''PrivilegesRequired=none''
+
| Admin Install (Elevation) || User Install (No Elevation)
-
*** Inno will not present a UAC prompt and will continue to run as the original user
+
|-
-
*** You ''must'' install per-user (Standard user install)
+
! align="right" |PrivilegesRequired=lowest
-
*** You ''cannot'' install any per-machine data (which also means that you cannot use restartreplace or regserver)
+
| User Install (No Elevation) || User Install (No Elevation)
-
*** You ''can'' offer to run the app at the end of the install.
+
|}
 +
 
 +
=== Admin Installs ===
 +
{| border="1" cellpadding="10"
 +
! rowspan="2" |
 +
! colspan="3" |User Type
 +
|-
 +
! Administrator !! Standard User !! Standard User using "Run as administrator"
 +
|-
 +
! align="right" |Windows XP or below
 +
| Runs Normally || Error Message, Exit || (prompt for credentials)
 +
|-
 +
! align="right" |Windows Vista or above, UAC disabled
 +
| Runs Normally || Error Message, Exit || (prompt for credentials)
 +
|-
 +
! align="right" |Windows Vista or above, UAC enabled
 +
| UAC prompt for confirmation || UAC prompt for credentials || (UAC prompt for credentials)
 +
|}
 +
 
 +
Note that using "Run as administrator" is not recommended (and should be unnecessary on Vista with UAC anyway), as that will mean that the admin user is both the "current" and "original" user, which may produce surprising results for the user depending on what your script does.  (For example, it will mean that if you have an option to run your app at the end of the installation, it will run as the elevated admin user.)
 +
 
 +
Also note that Inno handles the UAC elevation internally; as such its manifest says "asInvoker" and it will not display the "admin shield".  This is not a bug.
 +
 
 +
* You ''must'' install per-machine (Administrative install).
 +
* You ''must not'' do any per-user setup within the install proper (since the user that the setup is running as may not be the user who is planning to use the software); see below for more discussion.
 +
 
 +
=== User Installs ===
 +
* Inno will not present a UAC prompt and will continue running without elevation.
 +
* You ''must'' install per-user (Standard user install)
 +
* You ''cannot'' install any per-machine data (which also means that you cannot use restartreplace or regserver)
=== Per-User Actions ===
=== Per-User Actions ===
-
With the advent of Inno 5.2.0, the "runasoriginaluser" flag and "ExecAsOriginalUser" support function can be used to carry out tasks in the context of the original user running the installer.  This permits carrying out a limited amount of per-user setup on initial install, and also allows you to offer to run the application at the end of the install without having it end up running as the wrong user.
+
With the advent of Inno 5.2.0, the "runasoriginaluser" flag and "ExecAsOriginalUser" support function can be used to carry out tasks in the context of the original user running the installer (provided that the user did not use "run as administrator").  This permits carrying out a limited amount of per-user setup on initial install, and also allows you to offer to run the application at the end of the install without having it end up running as the wrong user.
Despite this, it is still best to keep per-user actions in the installer to a minimum, and instead modify your application so that it can upgrade or regenerate per-user data as needed.  This is because only one user is running the installer, but more than one may be running the application.  If your only upgrade code is in the installer, other users will be left out in the cold.
Despite this, it is still best to keep per-user actions in the installer to a minimum, and instead modify your application so that it can upgrade or regenerate per-user data as needed.  This is because only one user is running the installer, but more than one may be running the application.  If your only upgrade code is in the installer, other users will be left out in the cold.
Line 42: Line 76:
By far the majority of applications should perform an Administrative (PrivilegesRequired=admin) installation.  This requires the least amount of work from both setup writer and end user -- the app is installed once to a shared location (without touching per-user data at all), and then subsequently any number of users can run the application and create their own sets of per-user data.  The application itself of course should be set to not require admin permissions.
By far the majority of applications should perform an Administrative (PrivilegesRequired=admin) installation.  This requires the least amount of work from both setup writer and end user -- the app is installed once to a shared location (without touching per-user data at all), and then subsequently any number of users can run the application and create their own sets of per-user data.  The application itself of course should be set to not require admin permissions.
-
In some cases you may want to create a Standard (PrivilegesRequired=none) installation.  This is more work, since you'll have to add [Code] and Check functions to detect whether the install is being run by an administrator or not -- since Inno still requires a per-machine install if an administrator runs your PrivilegesRequired=none installation.  In the end you're going to write a lot more code (and consequently be more fragile) for limited benefit, as this mode is only useful if the software is never installed by any administrators.  (If even one admin installs it on a machine, then you might as well have done an Administrative install in the first place.)
+
In some cases you may want to create a Standard (PrivilegesRequired=lowest) installation.  These are potentially wasteful, as they require each individual user who wants to use the program to run the installer, leading to duplication of files on systems with many users.  Additionally, these limit the types of components that can be used (since some require per-machine installation), and as yet there is no officially sanctioned location where per-user applications should be installed.  But they do permit individual users to each have their own (potentially different versioned) copies of an application; depending on who you ask, this may be a good thing or a bad thing.
 +
 
 +
If using an older version of Inno that lacks PrivilegesRequired=lowest, the other alternative is to use PrivilegesRequired=none.  This is more work, since you'll have to add [Code] and Check functions to detect whether the install is being run by an administrator or not -- since Inno still requires a per-machine install if an administrator runs your PrivilegesRequired=none installation.  In the end you're going to write a lot more code (and consequently be more fragile) for limited benefit, as this mode is only useful if the software is never installed by any administrators.  (If even one admin installs it on a machine, then you might as well have done an Administrative install in the first place.)
== Best Practices ==
== Best Practices ==
Line 49: Line 85:
Almost all applications (whether under Vista or an earlier version) should have per-user data, especially for configuration options and the like.  Any time an app is shared by multiple users (which is becoming more and more common), each user will have their own preferences and won't want changes made by any other user to mess them up.  These preferences should normally be stored in {userappdata}\Your Company\Your Application or in HKCU\Software\Your Company\Your Application, which is user-specific.
Almost all applications (whether under Vista or an earlier version) should have per-user data, especially for configuration options and the like.  Any time an app is shared by multiple users (which is becoming more and more common), each user will have their own preferences and won't want changes made by any other user to mess them up.  These preferences should normally be stored in {userappdata}\Your Company\Your Application or in HKCU\Software\Your Company\Your Application, which is user-specific.
-
Note however that the installer should *not* be responsible for creating these (as discussed above) -- the application should do it itself from sensible defaults.  This is because the install process will only be run for one user, and if any other users run the application the data will not be present anyway.  (If the initial data is too complicated to reproduce automatically, then you can store a template copy in {app} and copy it to the user profile when your app starts up, if not already present.)
+
Note however that the installer should '''not''' be responsible for creating these (as discussed above) -- the application should do it itself from sensible defaults.  This is because the install process will only be run for one user, and if any other users run the application the data will not be present anyway.  (If the initial data is too complicated to reproduce automatically, then you can store a template copy in {commonappdata} or {app} and copy it to the user profile when your app starts up, if not already present.)
 +
 
 +
== Common Mistakes ==
 +
* Trying to install per-user data in an admin installer (see above).
 +
* Not marking your application with a Vista compatibility manifest.
 +
* Specifying anything other than "asInvoker" in your manifest -- the vast majority of applications should not require admin permissions at all, and of the few exceptions, most should only require admin permissions for small parts of their functionality and should elevate on demand (see MSDN).
 +
* Choosing different installation paths for "Vista" vs. "Before Vista".  The rules haven't changed, you've always been supposed to install in {pf} and keep user settings separate.  It's just more obvious in Vista since more users are running programs as non-admins.
== See also ==
== See also ==
Line 55: Line 97:
== External links ==
== External links ==
 +
*[http://www.microsoft.com/technet/technetmag/issues/2007/06/ACL/default.aspx New ACLs Improve Security in Windows Vista] on Microsoft TechNet
*[http://www.microsoft.com/technet/technetmag/issues/2007/06/ACL/default.aspx New ACLs Improve Security in Windows Vista] on Microsoft TechNet
*[http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/ Teach Your Apps to Play Nicely With Windows Vista User Account Control] from Microsoft MSDN Magazine
*[http://msdn.microsoft.com/msdnmag/issues/07/01/UAC/ Teach Your Apps to Play Nicely With Windows Vista User Account Control] from Microsoft MSDN Magazine
 +
*[http://technet.microsoft.com/en-us/library/bb456992.aspx Applying the Principle of Least Privilege User Acccounts on Windows XP]
 +
*[http://www.microsoft.com/technet/technetmag/issues/2006/08/LUABugs Problems of Privilege: Find and Fix LUA Bugs] on Microsoft Technet
 +
*[http://msdn.microsoft.com/en-us/library/bb530410.aspx Windows Vista Application Development Requirements] for User Account Control Compatibility
[[Category:Windows Vista]]
[[Category:Windows Vista]]

Revision as of 23:44, 27 January 2015

Windows Vista now includes a far stricter LUA system (LUA = Least-Privilege User Account; not to be confused with the programming language Lua).

This pretty much stops all applications making system wide changes without asking the user. (Note that the rules are still the same as they've always been -- but Vista enforces them more strongly.)

The recommended minimum version of Inno to use for Vista-capable installs is 5.2.0. For standard-user-only installs, you must use Inno v5.3.7 or later.

Contents

Types of Installer

Windows standards recommend two different "classes" of installer:

  • Administrative
    • Runs with admin permissions
    • Is expected to make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
    • Should not make changes to per-user areas such as HKCU and the current user's profile
    • Should default to installing to {pf}\YourAppName or similar.
    • Fully supported by Inno Setup (all versions, although 5.2.0 and above is best under Vista)
  • Standard user
    • Runs with standard user permissions
    • Is expected to make changes to per-user areas such as HKCU and the current user's profile
    • Must not make changes to per-machine areas such as Program Files, HKLM, and/or the All Users profile
    • Should default to installing to {userpf}\YourAppName or similar.
    • Supported by Inno Setup from v5.3.7; limited support on older versions.

Note that this means that administrative installs should not install Quick Launch icons, as they are per-user. (And of course they have also been deprecated by Microsoft.)

Inno's Installation Scenarios

User Type
Administrator Standard User
PrivilegesRequired=admin Admin Install (Elevation) Admin Install (Elevation)
PrivilegesRequired=none Admin Install (Elevation) User Install (No Elevation)
PrivilegesRequired=lowest User Install (No Elevation) User Install (No Elevation)

Admin Installs

User Type
Administrator Standard User Standard User using "Run as administrator"
Windows XP or below Runs Normally Error Message, Exit (prompt for credentials)
Windows Vista or above, UAC disabled Runs Normally Error Message, Exit (prompt for credentials)
Windows Vista or above, UAC enabled UAC prompt for confirmation UAC prompt for credentials (UAC prompt for credentials)

Note that using "Run as administrator" is not recommended (and should be unnecessary on Vista with UAC anyway), as that will mean that the admin user is both the "current" and "original" user, which may produce surprising results for the user depending on what your script does. (For example, it will mean that if you have an option to run your app at the end of the installation, it will run as the elevated admin user.)

Also note that Inno handles the UAC elevation internally; as such its manifest says "asInvoker" and it will not display the "admin shield". This is not a bug.

  • You must install per-machine (Administrative install).
  • You must not do any per-user setup within the install proper (since the user that the setup is running as may not be the user who is planning to use the software); see below for more discussion.

User Installs

  • Inno will not present a UAC prompt and will continue running without elevation.
  • You must install per-user (Standard user install)
  • You cannot install any per-machine data (which also means that you cannot use restartreplace or regserver)

Per-User Actions

With the advent of Inno 5.2.0, the "runasoriginaluser" flag and "ExecAsOriginalUser" support function can be used to carry out tasks in the context of the original user running the installer (provided that the user did not use "run as administrator"). This permits carrying out a limited amount of per-user setup on initial install, and also allows you to offer to run the application at the end of the install without having it end up running as the wrong user.

Despite this, it is still best to keep per-user actions in the installer to a minimum, and instead modify your application so that it can upgrade or regenerate per-user data as needed. This is because only one user is running the installer, but more than one may be running the application. If your only upgrade code is in the installer, other users will be left out in the cold.

Choosing an Installation Type

By far the majority of applications should perform an Administrative (PrivilegesRequired=admin) installation. This requires the least amount of work from both setup writer and end user -- the app is installed once to a shared location (without touching per-user data at all), and then subsequently any number of users can run the application and create their own sets of per-user data. The application itself of course should be set to not require admin permissions.

In some cases you may want to create a Standard (PrivilegesRequired=lowest) installation. These are potentially wasteful, as they require each individual user who wants to use the program to run the installer, leading to duplication of files on systems with many users. Additionally, these limit the types of components that can be used (since some require per-machine installation), and as yet there is no officially sanctioned location where per-user applications should be installed. But they do permit individual users to each have their own (potentially different versioned) copies of an application; depending on who you ask, this may be a good thing or a bad thing.

If using an older version of Inno that lacks PrivilegesRequired=lowest, the other alternative is to use PrivilegesRequired=none. This is more work, since you'll have to add [Code] and Check functions to detect whether the install is being run by an administrator or not -- since Inno still requires a per-machine install if an administrator runs your PrivilegesRequired=none installation. In the end you're going to write a lot more code (and consequently be more fragile) for limited benefit, as this mode is only useful if the software is never installed by any administrators. (If even one admin installs it on a machine, then you might as well have done an Administrative install in the first place.)

Best Practices

These are too long to discuss in any great detail here; the best idea is to look at the info available in MSDN. However one point that bears mentioning (because it seems to be a common mistake) is where data should be stored.

Almost all applications (whether under Vista or an earlier version) should have per-user data, especially for configuration options and the like. Any time an app is shared by multiple users (which is becoming more and more common), each user will have their own preferences and won't want changes made by any other user to mess them up. These preferences should normally be stored in {userappdata}\Your Company\Your Application or in HKCU\Software\Your Company\Your Application, which is user-specific.

Note however that the installer should not be responsible for creating these (as discussed above) -- the application should do it itself from sensible defaults. This is because the install process will only be run for one user, and if any other users run the application the data will not be present anyway. (If the initial data is too complicated to reproduce automatically, then you can store a template copy in {commonappdata} or {app} and copy it to the user profile when your app starts up, if not already present.)

Common Mistakes

  • Trying to install per-user data in an admin installer (see above).
  • Not marking your application with a Vista compatibility manifest.
  • Specifying anything other than "asInvoker" in your manifest -- the vast majority of applications should not require admin permissions at all, and of the few exceptions, most should only require admin permissions for small parts of their functionality and should elevate on demand (see MSDN).
  • Choosing different installation paths for "Vista" vs. "Before Vista". The rules haven't changed, you've always been supposed to install in {pf} and keep user settings separate. It's just more obvious in Vista since more users are running programs as non-admins.

See also

External links

Personal tools
Ads: