I am quite new with NSIS.
I am trying to request administrator permissions in order to run the installer, as it messes around a bit with registries.
My problem with "RequestExecutionLevel" and "MULTIUSER_EXECUTIONLEVEL" is that they both absolutely block any non-Admin user from opening the installer, even when selecting "Run as Administrator" in the context menu.
I have tried using the RunAs DLL, but I have not found a single thread as to what to put in the $command variable passed to "RunAsW" function.
Here is my (pretty hacked-up) code:
StrCpy $0 0
StrCpy $1 ""
System::Call 'RunAs::GetAdministrators(w r1, *i .r0) i .r2 ? u'
System::Alloc 64
Pop $4
StrCpy $4 $2
StrCpy $5 ""
loop:
IntCmp $0 0 endloop
System::Call '*$4(w .r3)'
StrCpy $5 "$5|$3"
endloop:
System::Free $4 ; we free the memory used by the array
StrCpy $5 "$5" "" 1
!insertmacro MUI_INSTALLOPTIONS_WRITE "Settings.ini" "Field 1" "ListItems" $5
!insertmacro MUI_INSTALLOPTIONS_DISPLAY "Settings.ini"
!insertmacro MUI_INSTALLOPTIONS_READ $1 "UserPass" "Field 1" "State"
!insertmacro MUI_INSTALLOPTIONS_READ $2 "Settings.ini" "Field 2" "State"
StrCpy $3 "%%LOGONSERVER%%"
StrCpy $3 0
StrCpy $4 0
System::Call 'RunAs::RunAsW(w r1, w r2, w r3, *w .r4) i .r0 ? u'
MessageBox MB_OK $0
IntCmp $0 1 success
Quit
success:
!insertmacro MUI_LANGDLL_DISPLAY
A lot of it is just guess work and trial and error. (btw - I also tried running through a loop to get all Administrators, but it seems the DLL was intended only for 32-bit machines, so...).
Anyway, my question is:
Does anybody know of a way (using "RunAs" or otherwise) to open a dialog requesting Username and password, check the credentials and continue with the installation only if they check out?
Also, I know there is a way to set up an installer so that it comes with that nice shield icon on it that lets users know that Admin permission will be requested. Does anybody know how to do that?
Any help would be very much appreciated, as this is the only thing currently preventing the deployment of my app.
Outfile RequireAdmin.exe
RequestExecutionLevel admin ;Require admin rights on NT6+ (When UAC is turned on)
!include LogicLib.nsh
Function .onInit
UserInfo::GetAccountType
pop $0
${If} $0 != "admin" ;Require admin rights on NT4+
MessageBox mb_iconstop "Administrator rights required!"
SetErrorLevel 740 ;ERROR_ELEVATION_REQUIRED
Quit
${EndIf}
FunctionEnd
Page InstFiles
Section
SectionEnd
is the basic code I usually recommend to make sure the installer is running as an Administrator.
IMHO it does not make sense to prompt for credentials on a custom page unless only parts of the install process requires administrator access and the other part requires access to the users profile. If this applies to you then you should take a look at the UAC plug-in (It is a bit complicated to use and makes it impossible for your exe file to get the shield overlay icon)
I don't think the RunAs plug-in works correctly on Vista+ when UAC is on so trying to get it to work might be a dead end...
The recommended way to get the shield is to request elevation in the exe manifest, RequestExecutionLevel admin does that. If you don't use RequestExecutionLevel at all in your script your installer might be detected as a legacy installer and it will also get the shield overlay.
In Windows Vista, if an executable file requires elevation to launch,
then the executable's icon should be "stamped" with a shield icon to
indicate this fact. The executable's application manifest must mark
"requireAdministrator" to designate the executable as requiring a full
administrative access token. The shield icon overlay will also be
automatically placed on executables that are deemed to require
elevation as per the installer detection heuristics. For example, a
file named setup.exe will automatically receive a shield icon overlay
even if the executable does not have an embedded application manifest.
Related
Once opened the browse dialog when installing using NSIS, it is showing the list of drivers, folders, mapped drives, removable drives and network folders. How to filter it and show only the local drives and folders from the Browse dialog?
You cannot change the way the directory page works, you would have to write a custom page and a custom plug-in if you want to filter the folder dialog.
You can however validate the directory and block the user from moving to the next page:
!include LogicLib.nsh
Page Directory
Page InstFiles
!define /IfNDef DRIVE_FIXED 3
Function .onVerifyInstDir
StrCpy $0 $InstDir 1
System::Call 'KERNEL32::GetDriveType(t"$0:\")i.r0'
${If} $0 <> ${DRIVE_FIXED}
Abort
${EndIf}
FunctionEnd
In this specific case that might not be a good idea because the user has no idea why they can't click the next/install button.
Instead you should stop with a message when the user tries to leave the page:
!include LogicLib.nsh
Page Directory "" "" ValidateDirPage
Page InstFiles
!define /IfNDef DRIVE_FIXED 3
Function ValidateDirPage
StrCpy $0 $InstDir 1
System::Call 'KERNEL32::GetDriveType(t"$0:\")i.r0'
${If} $0 <> ${DRIVE_FIXED}
MessageBox MB_ICONSTOP "You must specify a local fixed drive for some reason!"
Abort
${EndIf}
FunctionEnd
Note: Some USB storage devices will identify as a fixed drive.
Even if you do all this you cannot stop people from installing to a different drive type. They could temporarily change their drive letters, install, and then change them back etc.
To summarize, I need to check and/or prevent a user if he/she decides to shutdown the computer while the installer is running. Now I've researched for a while and came up with the following:
${If} ${AtMostWinXP}
System::Call `kernel32::GetModuleHandle(i0)i.r3`
System::Call `user32::CreateWindowEx(i0,t"STATIC",t"MyApp",i0,i0,i0,i0,i0,i$HWNDPARENT,i0,ir3,i0)i.r1`
${ElseIf} ${AtLeastVista}
System::Call `user32::ShutdownBlockReasonCreate(ir1,w"MyApp is running and still needs to clean up before shutting down!")i.r0`
${EndIf}
However the above snippet isn't working. Am I missing something? I've tried using just:
System::Call `kernel32::GetModuleHandle(i0)i.r3`
System::Call `user32::CreateWindowEx(i0,t"STATIC",t"MyApp",i0,i0,i0,i0,i0,i$HWNDPARENT,i0,ir3,i0)i.r1`
System::Call `user32::ShutdownBlockReasonCreate(ir1,w"MyApp is running and still needs to clean up before shutting down!")i.r0`
As the first two calls are meant for Windows XP and earlier and the third call is meant for Windows Vista or later but is ignored by Windows XP and earlier I believe (I have no evidence to support this theory). This too isn't working.
Also, I can use user32::ShutdownBlockReasonCreate(ir1,w"$(PreventShutdown)")i.r0 instead of using the entire string in the above snippet for different language support, right?
Your code for Windows XP makes no sense, the window needs to handle WM_QUERYENDSESSION to block the shutdown. Luckily NSIS already handles WM_QUERYENDSESSION for you.
Use something like this for Vista and later:
LoadLanguageFile "${NSISDIR}\Contrib\Language Files\English.nlf"
LangString BlockReason ${LANG_ENGLISH} "Installer blah blah"
LoadLanguageFile "${NSISDIR}\Contrib\Language Files\Swedish.nlf"
LangString BlockReason ${LANG_SWEDISH} "Installer bork bork"
!include nsDialogs.nsh ; For WS_CHILD
!define /ifndef WS_POPUP 0x80000000
!include LogicLib.nsh
Function CreateShutdownBlockReason
StrCpy $1 $hwndParent
${If} $1 Z= 0 ; $hwndParent is 0, create a new window for silent installers
System::Call 'USER32::CreateWindowEx(i0, t "STATIC", t "$(^Name)", i ${WS_CHILD}|${WS_POPUP}, i0, i0, i0, i0, p r1, i0, i0, i0)p.r1'
${EndIf}
System::Call 'USER32::ShutdownBlockReasonCreate(p r1, w "$(BlockReason)")'
FunctionEnd
Function .onInit
IfSilent 0 +2
Call CreateShutdownBlockReason ; .onGuiInit is not executed in silent installers
FunctionEnd
Function .onGuiInit
Call CreateShutdownBlockReason
FunctionEnd
I'm not sure if a silent installer will be able to block the shutdown but this is the best you can do without a plug-in.
I have an NSIS installer for an application, which can be run as normal user. But if the user wants to install into the "Program Files" directory, it can still be accomplished by starting the installer with administrator privileges.
Now I have the problem, that the uninstaller is started with user privileges by default, even if the installation took place as administrator. This causes the uninstallation to silently fail. Even worse: It even states that the uninstall process was successful without being able to delete any files.
My question is: Is it possible to create an uninstaller during the installation, which requires (or better: requests itself with) the same privileges as the installation process?
You would have to implement this check yourself. You can check if you are admin in the installer with the UserInfo plugin and then store the result in a .ini, the registry or append the info to the uninstaller.exe:
InstallDir $temp\instdir
Section
UserInfo::GetAccountType
Pop $0
StrCmp $0 "Admin" 0 +2
StrCpy $0 1
IntOp $0 $0 & 1 ; $0 is now 1 if admin or 0 if not
SetOutPath $InstDir
WriteUninstaller "$InstDir\Uninstall.exe"
FileOpen $1 "$InstDir\Uninstall.exe" a
FileSeek $1 0 END
FileWriteByte $1 $0
FileClose $1
SectionEnd
Section Uninstall
FileOpen $1 "$ExePath" r
FileSeek $1 -1 END
FileReadByte $1 $0
FileClose $1
DetailPrint "Installer was admin: $0"
SectionEnd
I just read bunch of answers about setting permissions to directory by NSIS AccessControl plugin, but all those only show basic usage copy pasted from plugin site... It only shows cases ALL or NOTHING... but how do I disable ALL permissions to directory for everyone except System and Administrators?
AccessControl::DisableFileInheritance "$temp\test.tmp"
Pop $0
DetailPrint $0
AccessControl::ClearOnFile "$temp\test.tmp" "(S-1-5-18)" "FullAccess"
Pop $0
DetailPrint $0
AccessControl::SetOnFile "$temp\test.tmp" "(S-1-5-32-544)" "FullAccess"
Pop $0
DetailPrint $0
This might not be enough, you should probably also use SetFileOwner and maybe SetFileGroup...
I have an installer that can handle command-line parameters and /S silent installation. I recently upgraded the installer to better conform to standards for Vista / W7 UAC management by using the UAC plugin and switching the RequestExecutionLevel from admin to user.
The tests shown that the UAC plugin is working well for rights elevation in GUI mode and command line silent mode (though the "silent" installation is not actually completely "silent" due to the elevation dialog).
Now I am told by customers that while wrapping my setup into a third-party deployment tool, their tool is getting a 1223 (ERROR_CANCELLED) error code (that seems to be "elevation cancelled by user"). My setup does not return error codes directly via errorlevel, so I am guessing that this code is returned somewhere from the UAC plugin that seems to perform the elevation with a hack around the system "runas" dialog.
am I right about the origin of the returned code? Though when I cancel the elevation dialog I get a errorlevel 5 (access denied) and not 1223
to integrate the UAC plugin I am using a InitElevation macro that is call at the beginning of .onInit, is it OK?
I am not sure to understand correctly the behavior of the UAC plugin in silent mode: the key seems to be in the _() function of the plugin dll, in the 0 case of the switch. If the NSIS dilaog is not visible (or not existent?) due to silent mode, could it make fail the "runas" invocation? In my test environment, while calling the silet setup from command line it is ok, but what if called from a deployment tool?
Macro to integrate the UAC plugin:
!macro InitElevation thing
uac_tryagain:
${Debug} "Init UAC_RunElevated"
!insertmacro UAC_RunElevated
;${debug} "$$0=$0 $$1=$1 $$2=$2 $$3=$3"
${Switch} $0
${Case} 0
${IfThen} $1 = 1 ${|} Quit ${|} ;we are the outer process, the inner process has done its work, we are done
${If} $3 <> 0 ;if we are admin
System::Call "kernel32::GetCurrentProcessId()i.r0"
${If} ${UAC_IsInnerInstance}
; If we are in the elevated process, we need to get our grandparent PID for console
${GetProcessParent} $0 $ConsoleParentPID
;${Debug} "From elevated $0 process, parent process is $ConsoleParentPID"
${GetProcessParent} $ConsoleParentPID $ConsoleParentPID
;${Debug} "grand parent process is $ConsoleParentPID"
${Else}
;${Debug} "We are an already elevated process"
StrCpy $ConsoleParentPID -1
${EndIf}
${Break} ;we are admin (after elevation or not), let the show go on
${EndIf}
${If} $1 = 3 ;RunAs completed successfully, but with a non-admin user
MessageBox mb_YesNo|mb_IconExclamation|mb_TopMost|mb_SetForeground "This ${thing} requires admin privileges, try again" /SD IDNO IDYES uac_tryagain IDNO 0
${EndIf}
;fall-through and die
${Case} 1223
MessageBox mb_IconStop|mb_TopMost|mb_SetForeground "This ${thing} requires admin privileges, aborting!"
Quit
${Case} 1062
MessageBox mb_IconStop|mb_TopMost|mb_SetForeground "Logon service not running, aborting!"
Quit
${Default}
MessageBox mb_IconStop|mb_TopMost|mb_SetForeground "Unable to elevate , error $0"
Quit
${EndSwitch}
${Debug} "End UAC_RunElevated init"
!macroend
Macro invocation (beginning of .onInit):
;abort if not started by administrator
!insertmacro InitElevation "installer"
${If} ${UAC_IsInnerInstance}
${AndIfNot} ${UAC_IsAdmin}
SetErrorLevel 0x666666 ;special return value for outer instance so it knows we did not have admin rights
Quit
${EndIf}