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.
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.
Here is the issue that I am having,
I have a C++ application that runs by writing data to .txt files and I want to create an MSI Package for the application.
When I build and run my app all is fine but when I run my MSI Setup File the created application does get granted the correct privileges to function.
I can't find a way to allow the app to write to the .txt files needed even if I include them in the package and set them as system files.
If I "Run as administrator" all is well but that isn't really plausible as I need it to function while "Running as User".
Is there anyway to prompt the user while installing to agree to an install with admin rights, so it doesn't have to be done manually before a prompt each launch.
Anything that can get my code running again would be brilliant, thanks.
Longer Writeup: System.UnauthorizedAccessException while running .exe under program files (several other options in addition to the ones listed below).
Per-User Folder: I would think you should install the files in question to a per-user folder (writeable for user - for example My Documents), or as templates to a per-machine folder (not writeable for normal users - for example %ProgramFiles%) and then have your application copy the templates from the per-machine location to the current user's My Documents folder - for example. Then you write to the files there - where a regular user will have write access. I suppose you could also write to a network share which is set up for users to have access.
Elevation: It is possible, to require the application to run elevated (link might be outdated - for .NET it is slightly different), but this is a horrible approach for something as simple as writing to text files. I would never require such elevation. Elevated rights are pervasive, and you don't want your application to run with the keys to the city - you become a hacker target and bugs in your tool become armed and dangerous.
ACL Modification: It is also possible to install the text files to a per-machine location and apply ACL permissioning to them so that they are writeable for regular users even if they don't have elevated rights. There is some information on how to do this here (bullet point 2). This approach is frowned upon in this day and age, but it will work. Be on the alert that your ACL permissioning shouldn't be too tight, in case you write to a new file, delete the old one and rename the new file to the old name during your write operation - you need file create in addition to file write obviously - there is very fine-grained control in NTFS. GenericWrite should do the trick I think.
Some Links (loosely connected, added for easy retrieval):
Create folder and file on Current user profile, from Admin Profile
Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?
Create a .config folder in the user folder
There is no connection at all between the install of an application and the running of an application regarding privileges. In other words there is nothing you can do in an MSI install that grants elevated privileges to the app being installed. It would be a massive security breach if a limited user could create an MSI setup that then installed an app that ran elevated.
So this question is actually nothing to do with Windows Installer - it's about whether you require users to be limited users or elevated users. If it's acceptable that users must be privileged, then you give the app an elevation manifest. If limited users will use it, then all writes or modifications to files or registry entries must be to locations available to limited users. It also means that the app won't be able to perform privileged operations, such as starting or stopping services.
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 a Win32 application that includes an EXE, an ActiveX control (DLL) and a COM server (EXE) and I am using Inno Setup 5 to build my installer. Many of our customers use limited user accounts where the user has no admin rights and because the COM components require to be registered (which writes to HKEY_CLASSES_ROOT), my setup file must run with elevated (admin) privileges. I think this in unavoidable (sadly, I can't use registration-free COM because of the EXE COM server I have). However, I would like to create an update installer that can be ran as a limited user and am looking for some advice.
What I am thinking is the following:
The initial setup (first time installation) installs the application into %ALLUSERSPROFILE%\Application Data\CompanyName\AppName instead of %PROGRAMFILES%. The COM components are registered as normal (as they won't already exist).
Subsequent updates (using a different Inno Setup script) will simply copy the new files into %ALLUSERSPROFILE%\Application Data\CompanyName\AppName. Hopefully even a limited user will have write access to this folder and as the COM components have already been registered, admin access won't be required.
This would mean that my customers could upgrade to the latest and greatest version without the hassle of using an Administrator account. Is this acceptable or is this likely to bite me on the backside? I'm pretty sure Google Chrome does something similar but as it has no COM components (as far as I can tell) even the initial setup can be as a limited user.
Any advice from others who have faced this issue would be very welcome indeed.
OK, I found a way to create a limited-user installation script with both my COM server and COM objects being registered per-user.
I am using the latest version of ATL (v9) that ships with MSVC 2008 to create my COM server and COM objects. Turns out that you can register the COM server per-user via the new /RegServerPerUser switch. I tested this with limited user accounts on XP, Vista and Windows 7 and it works perfectly.
Next, the COM controls. Again, ATL9 to the rescue. You can register a control per-user by ensuring that RegSvr32 calls your control's DllInstall function, passing it a command-line parameter of user. So, to register a control in this way you simply do:
regsvr32.exe /i:user /n MyControl.DLL
Again, I tested this on XP, Vista and Windows 7 and it works fine.
I then made the following changes to my Inno Setup script:
The default installation folder will be {pf} (i.e. C:\Program Files) if the user has Admin rights. If not, then it defaults to {commonappdata} (i.e. C:\Documents and Settings\All Users).
Register my COM server using the new /RegServerPerUser switch.
I removed the regserver flags from my COM objects and instead added support to call regsvr32 using the new 'user' switch.
All of these changes are easy to do using the Inno Setup {code} feature.
Thanks to Kim for setting me down the per-user COM install path.
I don't know for sure, but I seem to recall COM servers support per-user installation, and maybe that goes for EXE servers as well.
If so, change your registration code to write information to HKEY_CURRENT_USER\Software\Classes instead of HKEY_CLASSES_ROOT.
The COM infrastructure should do the lookup first per-user and then per-machine.
It's worth an experiment anyway.
If you dumped inno-setup and used MSIs - MSI files support the idea of limited user installation of patches. An administrator must authorize the initial install, thereafter, digital signatures in patch msi files are processed by the elevated msi service without requiring user elevation.
You can duplicate this basic idea yourself - during an initial administrative install, install a service component that has the necessary access. When processing patches, ask the service process to process the EXE COM server registrations.
You need to rethink your approache ... write access to a folder than can also allow for program execution by the same user is the cause for 99% of all virus/malware functionality. Please learn a little about Software Restriction Policy and the new App Locker behavior built into Windows 7 so that the computing infrastructure can move forward not backward.
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.