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.
Related
We have an exe which actually checks the contents of a folder and then kicks off a windows service to do some processing on the files in that folder.
So, we made this exe as part of System start up program so it runs everytime the system reboots/starts.
Now the user is very annoyed as he gets pop up for UAC everytime he restarts. But we need to have admin rights for this exe as it kicks off a windows service. Therefore I researched and found a couple of solns for this prob.
This and This
But couldn't decide which is better and less vulnerable for security implications.
Another potential solution can be in the code of .exe itself detect the system start up and if we have any content in the target folder then only ask for UAC from user and kick off the windows service . Else just don't run the exe. I am not sure how to do this in C++. Any pointers would be helpful. If there is any better solution, always welcome.
You probably want to use Task Scheduler here.
Just create a task as part of the install process, with "When the computer starts" as the trigger, and set the "Run with highest privileges" security option.
The problem is that you're mixing up the system and user sessions.
If the processing of those files is done on behalf of a user, it probably should not be done by a service. What if two users wanted their files processed? What security context should the service use for that? And obviously you shouldn't need Administrator right to process some user files.
If the service is performing some system-level task, it shouldn't depend on a user. And in fact running at startup suggests you want this mode. (User applets start at login, not after reboot). The main problem in your design therefore seems to be that you try to run an app (with UI) at the wrong moment which requires far too many permissions (causing UAC). Redesign the service so that it does all the tasks which require admin permissions, and when installing the service set it to start automatically. This still requires UAC at installation, but that is when UAC is expected.
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.
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.