Talk:UAC plug-in: Difference between revisions
(updated issue with tmp file. Running NSIS as admin makes it disappear.) |
|||
(13 intermediate revisions by 7 users not shown) | |||
Line 1: | Line 1: | ||
it's rather annoying that an installer elevated by this plugin does not strip its own commandline arguments after the elevation. it will prepend "/UAC=:(some digit) /NCRC" once elevated. i can strip this away with an additional function, but this is not what i'd expect to happen. also, this does not seem to be documented at all, i guess this can drive people crazy. | |||
---- | |||
There is a bug in branch 0.2. After the UAC request the installer is opened in the background if there is another window (e.g. explorer) open. Changing the dll and commands to branch 0.1 solves the problem. Tested with v0.2.2c and NSIS 2.46 on Win7 x64. | There is a bug in branch 0.2. After the UAC request the installer is opened in the background if there is another window (e.g. explorer) open. Changing the dll and commands to branch 0.1 solves the problem. Tested with v0.2.2c and NSIS 2.46 on Win7 x64. | ||
Line 143: | Line 147: | ||
I am no longer testing with the unofficial unicode fork and the current unicode nsis in svn is broken (Drop by the IRC channel and I might give you a unicode version you can play with) [[User:Anders|Anders]] 22:47, 19 September 2011 (UTC) | I am no longer testing with the unofficial unicode fork and the current unicode nsis in svn is broken (Drop by the IRC channel and I might give you a unicode version you can play with) [[User:Anders|Anders]] 22:47, 19 September 2011 (UTC) | ||
Is it still the case that the Unicode version has problems? I'm currently using Firefox's Unicode build, but as far as I can tell that is an older version. 15 April 2013 | |||
== tmp file problem == | == tmp file problem == | ||
Line 158: | Line 164: | ||
PS - this is really handy, and I very much appreciate your work. Thanks, Anders. | PS - this is really handy, and I very much appreciate your work. Thanks, Anders. | ||
[[User:Msarahan|Msarahan]] 14:01, 30 September 2011 (UTC) | [[User:Msarahan|Msarahan]] 14:01, 30 September 2011 (UTC) | ||
== UAC_AsUser* error == | |||
Got error from NSIS 3.0b compiler when compiling UAC's example scripts | |||
:!insertmacro: UAC_AsUser_Call | |||
:Push: $0 | |||
:GetFunctionAddress: $0 getdumpinfo!undef: "_UAC_ParseDefineFlags_orin_f2" not defined! | |||
:Error in macro _UAC_ParseDefineFlags_orin on macroline 12 | |||
:Error in macro _UAC_ParseDefineFlags_Begin on macroline 4 | |||
:Error in macro _UAC_ParseDefineFlagsToInt on macroline 1 | |||
:Error in macro UAC_AsUser_Call on macroline 5 | |||
:Error in script "C:\Program Files (x86)\NSIS\UAC_AdminOnly.nsi" on line 66 -- aborting creation process | |||
But work fine on NSIS 2.46 | |||
[[User:Msafwan|Msafwan]] ([[User talk:Msafwan|talk]]) 05:48, 25 May 2015 (UTC) |
Latest revision as of 07:18, 25 May 2015
it's rather annoying that an installer elevated by this plugin does not strip its own commandline arguments after the elevation. it will prepend "/UAC=:(some digit) /NCRC" once elevated. i can strip this away with an additional function, but this is not what i'd expect to happen. also, this does not seem to be documented at all, i guess this can drive people crazy.
There is a bug in branch 0.2. After the UAC request the installer is opened in the background if there is another window (e.g. explorer) open. Changing the dll and commands to branch 0.1 solves the problem. Tested with v0.2.2c and NSIS 2.46 on Win7 x64.
--Anders 21:02, 5 October 2010 (UTC) Yes, the other version has some ugly hacks to try to fix this, the problem is, when you elevate in .onInit (Before there is any UI) the outer process loses the foreground window control.
WARNING
There is a fairly large issue with this method if you are writing to HKEY_Current_User during your install.
The process relies on the initial Installer (The user one) being called as the current user, and then elevating the second process as admin for the admin tasks
If the user does either of the following:
- Opens the installer via the menu "Run As Administrator"
- Or calls the installer from their OWN installer which is running as admin
..you end up with *BOTH* processes running as ADMIN, and any HKEY_Current_User keys are written to the Administrators registry, not the user who tried to do the install.
I have found no fix for this. Microsoft wants Admin installs to specifically use HKEY_Local_Machine
--Anders 16:36, 23 November 2010 (UTC) Yes, but if the user used "Run As Administrator", that is what they wanted, I don't really see the issue there. RunAs/Secondary logon has been around since 2000, if they ask for a different user, that is what they get. And as you point out, Admin/Shared/All users installs should really only write to HKLM (I keep pointing this out, but it does not seem to stick)
Awesome stuff. Used and approved.
In a domain-based network it is important to provide credentials with standart "user\domain" form (as it is displayed into runas dialog and many other places in system). Unfortunally used function CreateProcessWithLogonW() uses different form of this - "user@domain" :( So...we need a to deal with this and provide onthefly conversion. I suggest add this pice of code immediately before CreateProcessWithLogonW call (RunAs.cpp):
#include <wchar.h> if(swscanf(wszUName, L"%s\\%s", wszDomain, wszUser) > 1) { wcscpy(wszUName, wszUser); wcscat(wszUName, L"@"); wcscat(wszUName, wszDomain); }
--Anders 01:11, 25 September 2007 (PDT) RunAs.cpp is only used if the user is non admin,running on Vista with UAC off (And it is only there since the built in RunAs seems to be broken) I don't have a domain to test on, but I will try to look into this
--Anders 02:04, 25 September 2007 (PDT) Is "\\machine\user" a legal credentials form? what about "\\domain\user"? Please try test build @ http://rapidshare.com/files/58108814/UAC_v0.0.6c_TestBuild.zip.html and report back
Anders 16:26, 13 October 2007 (PDT) Fix now added to new build (v0.0.6c), old version can be found @ http://stashbox.org/43690/UAC%20v0.0.6b.zip
new UAC build works very good in 'domain networks' enviroment! Thank you very much for developing!
- I found interesting new thing...How about members of 'Power users' group ?
According to MSDN documentation - members of this group have many available actions... for example register COM and ActiveX objects (regsvr32.exe my.dll ....), complete write access to 'programm files' directory... I think not all installers required *strictly* admin privelegues...
Maybe function who test for 'administrators' privelegue can test for 'power users' and indicate its presence ?
--Anders 20:59, 22 October 2007 (PDT) First off, the power users group is not really supposed to be used anymore. But, there is nothing in the UAC plugin that says you have to be admin(IIRC), you are already doing the admin check yourself in your .OnInit, you could call the UserInfo plugin instead of checking the "admin register" to allow power users (I'm not sure if this will work on Vista with UAC on, only admins are listed in the UAC dialog AFAIK. On pre Vista or UAC off, there should be no problems(This has never been tested, YMMV))
- Another interesting thing: Perhaps this is outside your control but when you try to elevate your permissions using an Admin account which uses a blank password (i.e. "") there is a windows error that states the admin account must have a non blank password. -Brad (brad@jittr.net)
--Anders 03:20, 31 October 2007 (PDT) http://forums.winamp.com/showthread.php?postid=2189159#post2189159
UAC error codes
I tried two of the example programs on a "Virtual Vista" machine. They both failed. I got an "unable to elevate, error 87" error. Is there a list of error codes someplace where we can look up an error to try and figure out what's wrong?
--Anders 10:57, 18 February 2008 (PST) Error codes are just normal windows error codes from GetLastError, please upload a script with this problem so I can take a look at it
Install instructions
I just added some basic instructions on how to install into NSIS, because the 'A' and 'U' directories had me flummoxed for a bit (obvious now, of course!). Maybe there could be a README entry on this, too, and perhaps rename them "ANSI" and "Unicode" for the hard of thinking? But anyway, this is a great solution to an otherwise nightmarish problem - thanks! Paul Clark 82.68.4.230 10:00, 22 July 2009 (UTC)
How to suppress UAC
I am working on a installer needs run automatically, without any user control. But the UAC pop-up will always be there, if the UAC is on. Is there a way to suppress the UAC pop-ups?
To perform admin tasks, elevation is required, that is the whole point of UAC. If you don't need admin rights, use RequestExecutionLevel User (And don't use the UAC plugin) --Anders 20:51, 7 October 2009 (UTC)
Possible problem with Guest user under Windows Xp
In the function SysQuery_IsServiceRunning(), the call to OpenSCManager() fails if executed by Guest user. The cause seems to be that the Guest is a special user (less than limited user) that can not to connect to the Service Control Manager. Avoiding such check, the install works also for Guest user.
UNC paths
I've been using this in the PortableApps.com Launcher, and it's causing failure to find files in the inner instance; today I've tracked that down to the fact that it's apparently turning a perfectly good local path into a UNC path, which the Launcher explicitly can't cope with due to drive letter replacements for portability. Can I avoid these UNC paths in any way, or do I need to convert them back myself (which is messy as there's no Windows API DLL call for this direction) and then use a different variable to $EXEDIR all the way through the script? -- ChrisMorgan
Where does this UNC path come from? I don't know what you mean by "drive letter replacements" but remember that mapped drives (probably subst also) are per user and UAC elevation can happen with a different user without these mappings --Anders 18:16, 25 February 2010 (UTC)
- On thinking the issue over, I came up with a different solution; I created an environment variable and if $EXEDIR 2 is \\ then it does ReadEnvStr $EXEDIR (I discovered that $EXEDIR is actually writable, even if not advertised as such), so for the moment I'm OK. I still can't understand why it's running a UNC path. (I can't test it properly on Wine, Wine reports 1233 straight away and so you never need/get an inner instance.) What happened was a tester ran R:\PortableApps.comLauncher.exe; R: was a share to \\dxp\r. The outer instance reported $EXEDIR as R:, but the inner instance reported $EXEDIR to be \\dxp\r. I haven't yet had it tested on a local path, but it has been said that it doesn't work - I suspect that it'll turn it into \\?\ or something like that.
- By "drive letter replacements" I meant e.g. searching for W:\ and replacing it with X:\ in a file, so that a portable application can keep things across drive letters. This is a normal technique at PortableApps.com. -- ChrisMorgan 03:18, 26 February 2010 (UTC)
- Another possible workaround is to set the EnableLinkedConnections policy ( http://support.microsoft.com/kb/937624 ) but that is not really something a portable app should be messing with. --Anders 19:06, 26 February 2010 (UTC)
Update the documentation?
Would be cool if you could update the wikipage so that it documents the latest version instead of just saying that it documents the old version.
--
Yes, a new docs (even small) would be great, especially since the new plugin has a completely new syntax. The old plugin elavates in .OnInit, apparently this is not recommended anymore, but where to evelate now?
Is there any documentation on the functions UAC.dll, UAC.nsh supplies. And don't say 'read the source' ;-). I would like to see a bullet for each function with description, what inparameters to use, what the return codes are, etc.
--
Just want to put my +1 here. Changing the syntax and not putting even a little example as documentation is REALLY bad. I need documentation!
Centered UAC dialog
In the current release, the UAC window appears on the top left edge of the screen. This patch moves it to the center of the screen:
UAC.cpp, OuterWndThread
int screenWidth=GetSystemMetrics(SM_CXSCREEN); int screenHeight=GetSystemMetrics(SM_CYSCREEN); int windowPosX=screenWidth/2; int windowPosY=screenHeight/2; if ( G().hwndOuter=CreateWindowEx(WS_EX_TOOLWINDOW,_T("Static"),NULL,/*WS_VISIBLE*/0,windowPosX,windowPosY,0,0,NULL,0,g_hInst,NULL) )
Link to patched DLL: http://rapidshare.com/files/444166927/UAC.dll
Dual Mode Example
I have tried using the dual mode example (UAC_DualMode.nsis) in the ZIP file on a Vista with UAC turned ON and it works fine except for one game killer.
When choosing to install for all users (admin role), after script starts up the the admin "thread", it does not bring it to the fore-ground, and does NOT close the "user" thread (though it is by all intents disabled!)
I am sure this will be easy to fix, but I am a newbie with limited experience in scripting.
Unicode version?
The latest download (v0.2.3b) seems to be missing the Unicode binary (and source). Was this intentional?
I am no longer testing with the unofficial unicode fork and the current unicode nsis in svn is broken (Drop by the IRC channel and I might give you a unicode version you can play with) Anders 22:47, 19 September 2011 (UTC)
Is it still the case that the Unicode version has problems? I'm currently using Firefox's Unicode build, but as far as I can tell that is an older version. 15 April 2013
tmp file problem
I'm totally new to NSIS, so this may be a bug in something else. I have been testing the UAC_DualMode example file. It worked fine the first time. Thereafter, I have only gotten strange messages. Windows pops up a window wanting to open a tmp file - these are always nst****.tmp files, where the *'s are random, but there are 4 of them. This seems to happen when the uninstaller is being created. The output log is here: http://dl.dropbox.com/u/2950894/output.log
The basic example still works fine.
Any idea what might cause this? Thanks. Msarahan 13:49, 30 September 2011 (UTC)
Update: When I run NSIS.exe as an administrator, this issue goes away and the example nsi file compiles successfully. I'm guessing some permissions somewhere aren't getting re-set.
Might it be worth advising users to run NSIS as administrators if their installer will require admin priveleges? Seems like a pain, but a simple workaround if this isn't an easy bug to fix.
PS - this is really handy, and I very much appreciate your work. Thanks, Anders. Msarahan 14:01, 30 September 2011 (UTC)
UAC_AsUser* error
Got error from NSIS 3.0b compiler when compiling UAC's example scripts
- !insertmacro: UAC_AsUser_Call
- Push: $0
- GetFunctionAddress: $0 getdumpinfo!undef: "_UAC_ParseDefineFlags_orin_f2" not defined!
- Error in macro _UAC_ParseDefineFlags_orin on macroline 12
- Error in macro _UAC_ParseDefineFlags_Begin on macroline 4
- Error in macro _UAC_ParseDefineFlagsToInt on macroline 1
- Error in macro UAC_AsUser_Call on macroline 5
- Error in script "C:\Program Files (x86)\NSIS\UAC_AdminOnly.nsi" on line 66 -- aborting creation process
But work fine on NSIS 2.46 Msafwan (talk) 05:48, 25 May 2015 (UTC)