Elevation Of Privileges | ![]() ![]() ![]() |
For the installer and the uninstaller, the privileges should be the same. This is why by default the "Request privileges" action in the uninstaller is a link to the action in the installer. If you have more complex requirements, you can have multiple "Request privileges" actions with appropriate condition expressions, each with a link in the uninstaller.
Since Windows Vista, "User Account Control" (UAC) limits privileges for all users by default. An application can request full privileges, with different effects for normal users and admin users: A normal user cannot be elevated to full privileges, so the user has to enter credentials for a different administrator account. A normal user is not likely to have these credentials, so by default the "Request privileges" action does not try to obtain full privileges for normal users. An admin user can be elevated. A UAC prompt will be shown in this case and the user simply has to agree in order to elevate privileges for the installer. Since it is not possible to write to the program files directory without elevated privileges, this elevation is performed by default. With the "Try to obtain full privileges if admin user" and the "Try to obtain full privileges if normal user" properties in the "Windows" category, you can configure this behavior according to your own needs.
By default, the installer will fail if the requested privileges cannot be obtained. You can deselect the "Show failure if requested privileges cannot be obtained" property in the Windows category to continue and let the user install into the user home directory or another writable directory.
Under some circumstances, for example if you want to manage services in your installer, you absolutely require full privileges. In this case, you can select the "Try to obtain full privileges if normal user" property in the Windows category. When you insert a service action and the elevation properties are not selected, you will be asked whether the necessary changes should be made automatically.
Similar to Windows, Mac OS X limits privileges for all users by default and normal users and admin users behave differently with respect to privilege elevation: A normal user cannot be elevated to full privileges, so the user has to enter the root password. A normal user is not likely to have the root password, so by default the "Request privileges" action does not try to obtain full privileges for normal users. To elevate an admin user, an authenticate dialog will be shown and users have to enter their own password. Contrary to Windows, admin users can always write to the /Applications directory, even without full privileges. That's why on Mac OS X no elevation of privileges is requested by default.
Like on Windows, the installer will fail by default if the requested privileges cannot be obtained. In the default setting this has no effect, because privileges are never requested.
Service installations require full privileges, so the "Try to obtain full privileges if admin user" and the "Try to obtain full privileges if normal user" properties in the Mac OS X category should be selected in that case. Again, service actions will suggest to make the necessary changes automatically when they are inserted into the project.
install4j does not support elevation of privileges on Linux and Unix. Partly this is due to the different incompatible systems of elevation, most notably "su" and "sudo" which cannot be easily detected. If full privileges are required, the user has to elevate the installer manually, either with "su" or with "sudo" or with the corresponding GUI tools. In this case, the "Show failure if current user is not root" has to be selected, so that an error message is shown if the installer is not started as root.
There are two strategies for elevating privileges: Either restart the main installation process, or start a helper process with full privileges. The UAC dialog on Windows and the authenticate dialog on Mac OS X are the same in both cases. However, the "Install Files" action is always executed in the main installation process. On Windows, where you only can write to the program files directory with full privileges, the preferred strategy is to elevate the main installation process. On Mac OS X, it is possible to write to /Applications for admin users, so the preferred strategy on Mac OS X is to start an elevated helper process. Also, the restart of the main installation process on Mac OS X is noticeable to the user in the dock.
If the "Request admin privileges" action performs a restart, all response file variables are transferred to the new installer process. This means that the "Request admin privileges" action does not necessarily have to be located in the "Startup" sequence. You could gather some user input and then decide if you need elevated privileges or not later on.
For your own scripts or custom code, the API offers a way to push a piece of code to the elevated
helper process or to the original process if they exist. This is done by wrapping the code in a
com.install4j.api.context.RemoteCallable
and calling
context.runElevated(...)
for the elevated helper process and context.runUnelevated(...)
for the original process with the RemoteCallable
. The RemoteCallable
must be serializable,
so its fields can be transferred to the other process. Its execute()
method that contains the code
returns a Serializable
so you can return a result to the calling process.
Several actions in install4j use this mechanism, as explained in the next section.
The following elements in install4j support the elevated helper process automatically:
com.install4j.api.windows.WinUser
classIf the main installation process is elevated, the original process is kept alive. It waits for the elevated process to finish and services requests for actions that should be executed as the original user. There are several actions that are automatically executed as the original user:
The "Run executable or batch file" and the "Uninstall previous installation" actions can both elevate or unelevate the executed process. Their "Execution account" property allows you to either execute them in the context of the main installation process ("Run as is"), push them to the elevated helper process ("Run as admin if possible") or push them to the original process that services requests by the elevated main installation process.
![]() ![]() ![]() |