I do have a Windows console application, written in C++ and compile with the console subsystem but when started from the command line, it does open a new window instead of reusing the same console window.
It seems that the cause is that executable has a manifest that requires admin privledges in order to run.
This was added in order to be able to properly read some keys form HKLM.
How can I solve this problem?
You do not need to specify a requestedExecutionLevel of requireAdministrator in the application manifest in order to make it able to read from HKLM without virtualization.
You do not need to elevate in order to read from HKLM. And so long as your process has an application manifest that specifies requestedExecutionLevel then it will not be virtualized. The conclusion therefore is that you need to specify a requestedExecutionLevel of asInvoker.
Details of registry virtualization can be found in the MSDN docs.
Related
I'm porting my application on Windows 8. Program uses path
C:\ProgramData\MyProgramName\
for storing backups.
It works good on Windows 7, but it got "Access Denied" when I run it on Windows 8.
What is the proper way and place to store my program's backups (not related to any particular user) ?
I see many programs storing their non-user related application data in the common application folder. Ok, actually what they do is create a folder inside the common application folder to store their data.
To get the path to the common application folder, you can call the SHGetFolderPath function with CSIDL_COMMON_APPDATA as the folder id. If don't have to support anything earlier than Windows Vista then you can call the SHGetKnownFolderPath function instead, and pass FOLDERID_ProgramData as the known folder id.
Ah! I did not know that the common application folder is not-writeable by normal users. Luckily there appears to be a recommended solution. See this article on MSDN, Data and Settings Management which states the following "If an application requires normal Users to have write access to an application specific subdirectory of CSIDL_COMMON_APPDATA, then the application must explicitly modify the security on that sub-directory during application setup. The modified security must be documented in the Vendor Questionnaire."
C:\ProgramData has security settings that prevent standard user from writing there. This is not new in Windows 8, Windows 7 was the same, and the equivalent folder on Vista is also secured in this way. Perhaps your Windows 7 environment has UAC disabled, or perhaps you have secured C:\ProgramData or C:\ProgramData\MyProgramName to permit write access to standard user.
There are a couple of approaches to the use of this folder. Some applications write there only during installation whilst the installer process is running elevated. Then the application itself, which runs as standard user, can read, but never attempts to write.
Another approach is for the installer to create a sub folder of C:\ProgramData that is secured to allow write access for standard user, or whatever user/group that you the developer deem appropriate.
Am working on a vc++ background application which installs in the program files folder. It works fine when it was manually started, it creates xml file in the same folder. But however the application is not creating the file when it was configured to startup.
Even when I provide the requireAdministrator privilege it is not creating the file at the startup.
This is same as the issue with Granting administrator privileges to an application launched at startup without UAC prompt?
but when program runs as Administrator it doesn't start at startup, this is my problem
But am working for a solution in vc++.
Please help am working on this more than a week
Did you add a proper manifest to your project?
In VC++ you must add one(http://msdn.microsoft.com/en-us/library/windows/desktop/bb756929.aspx)
Move the XML file to ProgramData (CSIDL_APPDATA).
I assume you have UAC enabled (i.e. UAC prompt appears). If that so, you would see it always when you start from Explorer, and will not see from Admin mode Visual Studio (since VS is elevated), and hence your process would be elevated.
But, when your process starts, the UAC won't appear, and your application will fail to start. It is best bet not to make your application requiring Administrator rights (why do you need?). You can save the data in some other folder.
If you must, you may need to create a service, which would start your application in elevated-mode (yes, without any UAC prompt).
Do check the system event reporting for your application, since this cannot be easily debugged.
I am developing a partition disk program, and for me to read the \\\\.\\PhysicalDrive0 I need admin rights.
I am wondering if it is possible, in the run time, for the program to gain admin rights? Is there any win api for that?
I want to do that because I want the program to execute with admin rights only when it is reading/writing the disk. For security reasons, I don't want the program to execute all the time with admin rights, because someone could find a bug (stack or heap overflow for example) in some module and execute arbitrary commands as adm.
You cannot acquire elevated privileges after the process has started. Your options are:
Put the part of your application that requires elevated privileges into a separate process and manifest that with requireAdministrator.
Run the part of your application that requires elevated privileges as an out-of-proc COM object.
I have never seen a way to transition rights once a process has begun executing. The only way I know of is for the process to be created as privileged.
I look forward to other answers in case there is another way.
(update)
The article Teach Your Apps To Play Nicely With Windows Vista User Account Control (about halfway down) confirms that admin rights can be granted only at process creation time.
You need to embed manifest with requireAdministrator flag
http://msdn.microsoft.com/en-us/library/bb756929.aspx
Project's Propeties (Alt + Enter) -> Linker -> Manifest File
-> UAC Execution level (in VS2015, in 2010 it's similar)
-> requireAdministrator or highestAvailable
Edit: Also, if it's updating program, simply make your program's name starting with Update and Windows will automatically recognize it.
I have an MFC application developed in VS Studio 2008 which reads and writes to a JSON file in its installation folder. It works perfectly in vista(administrator) BUT ONLY when UAC is turned off. When UAC is ON, the application isn't able to write to its JSON file. I figured I had to create a manifest file but I haven't really tried creating one.
Questions:
reference: http://msdn.microsoft.com/en-us/library/bb384691.aspx.
It says here that you can simply set the linker options in the Visual Studio development environment.
What values do I need to select for:
a) Enable User Account Control (UAC)? [I tried NO].
b) UAC Execution Level? [I tried highestAvailable].
c) and UAC Bypass UI Protection? [I tried Yes].
Do I need to add the manifest file in the software package (exe, Dll's, etc.)?
Thanks...
The whole concept of UAC is that you can not bypass it. If you could, it would be useless.
The only solution (which is what you should do anyway, not just because of UAC) is to never ever write files in the install folder but in %APPDATA% where it belongs.
You should copy this file to AppData. Modifying a file in Program Files will always trigger a UAC prompt. This operation requires admin privileges and manifest won't help you with that.
Adding manifest file you can only declare that the application needs UAC permisison. This way the user will be prompted for UAC on application start.
If this is what you want here you can find description how to do it.
Other aprroach is to install a service which runs with LocalSystem account and is allowed to do (almost) anything without asking for UAC permission. For this to work you have to implement inter process communication between your UI applicaiton and the service. Kernel objects shared between processes have to be created from the service with appropriate security attributes in order to be accessed form not elevated programs.
The installation of the service will prompt the user for UAC ( as most other installations )
You mentioned you tried manifesting the executable as
UAC Execution Level: highestAvailable
It should be set to requireAdministrator.
The difference is that highestAvailable will only elevate if the user really is an administrator who's been (UAC) stripped of their admin privelages. If they really are a standard user then it won't elevate.
On the other hand requireAdministrator will require that they elevate. If the user is not an administrator, they will be presented with a prompt to enter a Username and Password of someone who is an administrator; they'll have to call someone to come down and type in their username and password.
If the user already was an administrator, then requireAdministrator will just ask them to Continue.
Set the EnableLUA DWORD value in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 0 and reboot.
This will disable UAC without a problem, I would do it to all your users, with or without permission is up to you.
Works in Windows Vista and Windows 7 as well.
im writing an application that downloads and installs addons for programs which needs to save the data to program files (for the programs in question). Now this works fine on xp and vista with uac disabled however it is failing on normal vista due to the virtual folders.
How would one get around this with out needing to request admin rights every time the app started?
P.s. Program is written in c++, vis 2005
Edit: File system virtual folders: http://www.codeproject.com/KB/vista-security/MakingAppsUACAware.aspx
Only write to Program Files during installation. After that, write to the user folders.
You can elevate the apps privileges later, but you'll just be delaying the prompt. The whole point of UAC is to prevent random apps from writing to folders that require admin privileges. (ok, not the whole point, but a large portion of it.)
You could create a service with admin privileges and send commands to it to move the downloaded files into the desired target directories, but this opens up a user's system to being abused by other apps if you don't design it very carefully.
This article talks about getting apps to work nicely with UAC. Also, see this article here.
Microsoft recommended to me when I spoke to them to have to write a second application, which you manifest as requiring administrative privileges. You use this application to deploy your file from a safe location (such as the users programdata directory) to the program files directory (Note that if your DLL isn't signed then this is a massive security hole as a virus/malicious user could manipulate the file before your function call).
Your non administrative app can call this application which will trigger UAC. People who understand UAC won't care and happily will click your application. Those who hate it will have switched it off. The call to start the new process (which required admin privileges) will throw a win32 exception if the user cancels the UAC dialog so beware to catch that.
The problem in vista is that it tries to help you by virtualising your program files directory if you are not admin. By design there is NO way that you can write to the program files directory unless you're administrator.
Another option is to create all of your "updates" as MSI updates. That way the windows installer will trigger UAC for you and you could provide a logo for your software etc.
Option 3 is to use clickonce deployment which will allow you to automatically update your program without UAC but you live in a sandbox on the users system which may not work with your application's current design.
I got around uac by making a windows service that does the work i need and only runs while the app is running.