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.
Related
I have a multi-process application that was originally developed in XP and was originally designed with no regard to administrator privileges. We used to configure and sell computers with the software. We are now selling the application by itself, without the hardware, to be installed on user systems in a corporate environment. Currently our software package requires our users to run in administrator mode, which is not making us popular with our customers IT departments.
I have been working to remove items that obviously require administrator privileges (writing to HKLM in the registry, writing to the Program Files folders). However, Windows continues to require administrator rights to run the software. If I deny the rights, it closes with no logs. It has a lot of legacy code and so hints to find where the administrator access is happening has proven difficult.
Is there an easy way to see what is being accessed or done that is hitting Windows 10 admin requirements?
Currently I have removed moved writing of data files I could identify to the Program Data folder or to user documents. (depending on whether I want users to be able to easily find them or not).
Configuration files have been moved to user folders.
Registry key access has been kept to HKLU or read-only in HKLM.
Thank you all for the help. I ended up finding the answer in the C# based launcher for our software, which was starting all processes with the verb "runas" set:
try
{
myProcess.StartInfo.Verb = "runas";
myProcess.StartInfo.FileName = command;
myProcess.StartInfo.WorkingDirectory = workingDir;
myProcess.StartInfo.Arguments = prams;
myProcess.Start();
}
catch (Exception ex){}
I removed the "runas" verb and now the system is not requesting admin privileges on the started pieces of code.
I found the cause when I tried to setup a debug run from the Program Files directory and started the code without going through the launcher. (started in a debugger) The system did not request administrative permissions which led me back to the launcher. I recently got the launcher to run without needing administrative permissions and so I had assumed that the problem was in the other processes. Seems I was mistaken.
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 trying to release a C++ .Net application and am getting very frustrated with Windows UAC. I have not much experience with this as have always been writing for XP.
The program needs to update some properties that are stored in two XML files and every time it tries it gets access denied if it is not running with an Administrator account.
I have followed the recommendations from Microsoft and am writing all the files that need to be modified to the CSIDL_COMMON_APPDATA folder. The installer has an action that creates the [Organization}[Program] structure within the later and adds the security group Every One with full control privilege because by default, that directory is read only.
I have verified that the cretated directory [Organization}[Program] does actually contains the group and the privilege assigned after installing.
Also, the application has a manifest with a requestedExecutionLevel, which I have tried asinvoker and Highestavailable.
The application is still not being capable of writing to the directory unless the user is not logged as Administrator...
The machines are in a domain controled by a server 2003 but the clients are a mix of XP, vista and 7.
Please, could someone with more experience in this than I enlight me?
Should I use some other folder? The problem is that Different users might log into the computer and those settings are common, therefore the obvious User folder is not an option.
I cannot either add the user to the security of the folders with the installer because I don't know which user from the domain will use the program and I cannot do it from the program when starting because if the user does not have adminstrator rights the program will just be blocked.
Please, any advise or indication about what am I missing here?
This may discuss your problem. See especially
Your application's installer needs to set ACLs on your subdirectory of CSIDL_COMMON_APPDATA to allow users to access that directory as required by your application
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.