This has been on my mind for sometime. I can open task manager by pressing Ctrl + Shift + Esc and on the second tab (Processes), I can easily press Alt + S -- Show processes from all users to elevate my task manager without any prompts whatsoever. And voila, I have a powerful tool to play with. I've been unable to find any documents explaining this and I'm very curious about how this feat is achieved; since the button should actually ask for a prompt but does not.
What you are describing is called Auto Elevation. It is done by a lot more than just task manager, but there is no way to make your program do it. To auto elevate the following requirements must be met.
<autoElevate>true</autoElevate> must be in the assembly manifest.
It must be located in one of a handful of "secure" directories. A secure directory is one that standard users can't modify and they include %SystemRoot%\System32 and most of its subdirectories, %SystemRoot%\Ehome, as well as a handful of directories under %ProgramFiles% that include Windows Defender and Windows Journal.
It must be digitally signed by the Windows publisher, which is the certificate used to sign all code included with Windows (it's not sufficient to be signed by Microsoft, so Microsoft software that's not shipped in Windows isn't included)
You can do number 1 and 2 yourself, but there is no way you can fulfill requirement #3.
Related
We have an ancient win32 product that some customers still want to run in Windows 10, but in some cases several of its components (win32 executables) produce said message when run, while installing and after installing :
"Do you want to allow this app/program to make changes in your PC".
Is there any documentation of what Windows checks to emit the message ?
The message you're seeing is the UAC prompt, and it appears because Windows thinks the program wants admin privileges.
Ancient programs don't have manifests. Modern versions of Windows guess at whether really old programs require admin privileges. If the name of the program sounds like it would be an installer (e.g., setupfoo.exe), it will assume the program needs admin.
But many really old programs, even if they're not installers, often want admin privileges because they often try to do things like save files in the program's installation directory or change machine-wide registry values. If Windows detects a program attempting this and failing because it doesn't have admin privs, it might adjust the program's compatibility options so that next time it runs as an administrator. To check this, right-click on the executable file, choose Properties, and select the Compatibility tab. There you'll find a checkbox named "Run this program as an administrator."
To check if your program has a manifest, open the .EXE in Visual Studio (with just the regular open file command), or other resource viewer/editor tool, and look in the resources to see if it has an RT_MANIFEST resource.
If there is no manifest and the program is well-behaved, you can add one that sets the <requestedExecutionLevel> node to asInvoker.
If it has a manifest, look at the <requestedExecutionLevel> node in the XML. If it's there and it says requiresAdministrator, then there's probably nothing you can do. If it already says asInvoker, then something else is going wrong.
To provide or replace the manifest you have two options. You can create an external manifest file and place it in the same folder with the executable (for some versions of Windows, you also have to tell Windows to rely on the external manifest by changing a registry value).
Alternatively, you can use the manifest tool (mt.exe, which comes with Visual Studio) to embed an appropriate manifest in the executable itself (make a backup of the executable first!). In either case, you want to set the <requestedExecutionLevel> node to asInvoker to avoid the UAC prompt.
Note that, if the program really does need admin privileges, then providing a manifest that says it doesn't will cause the program to fail certain operations. The program might crash, or it might appear to work but silently fail to do something important (like saving your work).
Also note that manifests control other important things that you may have to get right, like marking whether the application is DPI-aware or what Windows versions it supports. So, if you try to add a manifest just to add asInvoker, you might also have to add some other important values. MSDN has lots of documentation on manifests and the manifest tool.
It's a common practice to disallow users from installing programs without elevated privileges, especially in larger companies. When the user runs the installation executable (whether .exe or .msi), the user is prompted for these admin credentials before User Access Control will allow the installation. A lot of programs that require installation take advantage of the default Windows installer .msi packaging or something similar, but an executable file could perform all the same functionalities, right?
Is it this common installation-packaging solution that tells Windows, "Hey, I'm an installer. Something is being installed."? Windows isn't analyzing the actual behavior of the executable file, right?
If your question is about asking for admin credentials, that's normal behavior when an executeable has a manifest that says it requires admin privilieges. I guess that if you say your InnoSetup requires admin privileges it will include a manifest requiring elevation, and Windows will show the elevation prompt.
There is no such thing as Windows InstallShield, in case you are thinking that InstallShield is a Microsoft Windows product. InstallShield is a 3rd party product that in many cases creates an MSI file. MSI files are marked (when built) as to whether they require elevation or not. It's the summary information strean Word Count that says whether the MSI requires elevation to install or not:
https://msdn.microsoft.com/en-us/library/aa372870(v=vs.85).aspx
In the case of an .MSI, sure, Windows automatically knows your installing something. I think your question is more along the lines of what about anything other then an .MSI? Windows has some heuristics built in that AFAIK are managed by the application compatibility team. They do things to detect what they is a setup (like file name, process name, inspection of the summary information stream and so on ) and perform various functions such as detecting a possible failed install, asking if it was an install and if it failed and them performing application compatibility shims such as version lying and forced UAC elevation prompting.
You get to avoid this ugly world my authoring properly designed MSIs. :)
MSIs can be authored per-user or per-machine. Per-user installs won't ask for elevation by default. Per-machine installs will ask for elevation once they hit the InstallExecuteSequence.
My MFC app usually runs with admin rights, however, there is one operation which needs admin privileges (activation of the software where the status must be saved to HKLM).
For now, I created two .exe files: The ordinary app and "Activation.exe" which must run as admin and has requestedExecutionLevel=requireAdministrator in the Manifest. The activation is started with a button which makes ShellExecute(Activation.exe).
However, both applications share lots of code so I would like to merge the two exe into one exe. But how do I make sure then that specific parts of the code are executed with admin privileges? This method should/must be compatible down to NT4.
One idea is to integrate the functionality of Activation.exe in the main exe using a switch (e.g. "myapp.exe -activate"). A small bootstrapper makes sure that it can only run as admin (requireAdministrator in Manifest) and does nothing more than ShellExec(myapp.exe -activate). But is this really the best way?
I don't know if it's the best way (no-one answered) but I did that now :) The bootstrapper has just requireAdministrator in the Manifest and does a ShellExecute to the main executeable with switch "/Activate" ...
I would typically use a call to ShellExecuteEx with a verb of runas to launch any executable as administrator, even if it's manifested asInvoker.
Note that on systems where UAC has been disabled, the resulting launch may not receive administrator privileges; I believe this caveat also applies to the approach of launching an exe manifested requireAdministrator.
I have a binary which creates and later removes entries from Program and Features (also comes up in Add/Remove Programs). While I can get UAC permissions when creating the entries, my requirements do not allow me to show a UAC prompt when I need to remove the entries. This makes sense as you should need admin permissions when deleting registry entries from HKLM.
But I have noticed that I am able to uninstall the entries from the Program and Features window without a UAC prompt. How is uninstalling from there, which invokes my binary anyways, different from me invoking my binary directly? Is there some way I can run my binary the same way and avoid the UAC prompt?
By default, UAC gives special treatment to the built-in Windows control panels, allowing them to silently elevate. Because of this, when your uninstaller is launched from Programs and Features it is already elevated and does not need to prompt.
There is no way to make Windows treat a third-party application in the same way, although the user can change the settings so that all applications elevate silently - or, conversely, so that control panels don't elevate silently.
I'm marking this as a community wiki because I'm not really looking for one complete answer. So if you feel like posting one or two things that will activate the UAC prompt instead of a comprehensive list then go ahead.
What actions in Windows will activate UAC? I'd like to avoid it as much as possible because my application doesn't need admin privileges. And I'm sure many other people want to avoid it.
Specifically, I would like to know if reading from the registry would activate it. Or writing to it?
You don't need to address the above question, just anything that will activate it is fair game.
It's really hard to Google anything about UAC because you get bombarded with articles about how to disable it. And I'd rather not have my application make the assumption UAC is disabled.
Nothing "activates" UAC.
If your application would fail to run as a standard user under Windows XP it will fail to run under Windows Vista or Windows 7 as a standard user.
What you are really asking is: what actions can a standard user not perform under Windows?
The things a standard user cannot do are pretty well known (they've been the same since Windows 2000). The main ones are:
modify anything in HKEY_LOCAL_MACHINE
modify anything in the Windows directory
modify anything in the Program Files folder
If you try to do any of those they will fail on:
Windows 2000
Windows XP
Windows Vista
Windows 7
Nobody should have been running as an administrator for day-to-day computer use. If your application did any of those bad things in Windows XP it would fail. The user would have to:
logon (or fast user switch) to an administrator
perform the administrative task
switch back to their real account
UAC is a convience mechanism, allowing you to easily temporarily switch to an administrator. Nothing you do will "trigger" it; you have to make it happen.
If you know your code needs to modify a file in C:\Program Files\My App\Data, then you should add a button on your form that will trigger the elevation.
You then need to launch an (elevated) copy of your program, do the thing, and close.
I created a launch4j installer (an exe-wrapper for java programs) and named it "MyApp.exe". It doesn't need any admin authentication. It just runs fine without any UAC prompt.
BUT: If I rename this installer to "install.exe" or "setup.exe", the UAC icon appears and I get a UAC promp when starting the installer.
Seems as if there are some "reserved words" in filenames that cause windows to start a program with elevated rights (UAC).