I have a problem with UAC on Vista/7. My installer with UAC Execution Level = requireAdministrator installs and runs my app. App UAC Execution Level = asInvoker. So first time app runned by installer -- it runs as administrator. Then, app creates some files to store self state. Later -- if app launched by user, not as administrator -- app can only read from created files, but can't overwrite them.. I tried to disable UAC in the app manifest, or build app without manifest but result still same -- every file created when app runned as administrator can't be overwritten when app runs as user. I tried some other installers like Inno Setup but there nothing like my problem... So my question -- why it happens in my case and how to fix it ? Thanks.
P.S. Important notes
1. Actually it is not installer. This is utility to update main app executables. Main app check server for updates, if any available -- downloads updates to the temp folder and then launch utility with elevated rights (http://www.codeproject.com/KB/vista-security/UAC__The_Definitive_Guide.aspx) in order to replace executables in the Program Files folder. Main app terminates just after launching utility.
2. All files application stores in the ProgramData\myAppName folder.
Are your installing application for current user only or for all users on the machine?
For per-user installation it makes sense for the installer to create initial application state in the user's AppData folder. MSI runs per-user installations NON-elevated, so there is no problem with files in AppData folder your applications cannot modify.
For per-machine installation it does not make sense to put anything to the specific user's AppData folder or anywhere under users profile location. New users can logon on the machine after application is installed and they would not have anything there.
That said, you have three solutions (actually two solutions and one hack):
Use per-user installation. Set ALLUSERS=2 and MSIINSTALLPERUSER=1. Your MSI will be run non-elevated. MSI is free to put any state files in AppData folder.
Use per-machine installation. Don't write to users's appdata. Instead, write initial state files into %ALLUSERSPROFILE%. They will be Read-only to application. Modify your application to copy initial state from %ALLUSERPROFILE% to current user profile on first run.
Add custom action to your installer to add user to ACLs.
(#3) is a hack and I don't recommend it, because your application would be broken for new users, or when user re-creates his profile on machine.
You should not start your main app elevated if it doesn't require administrator rights. What type of installer do you use?
MSI runs with current user privileges and elevates only to make changes to the system. After installation completes, you can start your main app and it will be run as the current user, non-elevated.
If you custom setup.exe, you can start your setup program non-elevated. When the time comes to install files, start another process (it can be the same executable) to install files and make system-wide changes. When this step completes, you can re-start your main app as non-elevated from the initial process.
Alternatively, with your current approach where setup and updater run elevated, follow the instructions at How do I start a program as the desktop user from an elevated app to start your main app non-elevated.
Note: the default permissions on ProgramData allow everyone to create files and folders but only the user that created them can modify the files (or administrator). To overcome this, you have two options:
Create data files directly in user profile. Each user will have their own data.
Create user profile data from common template stored in ProgramData, as suggested by Seva in option 2. In this case each user will also have their own data.
Or modify ACLs on your application data in ProgramData directory to allow its modification by everyone, not just the user that created the folder and files.
Related
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.
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.
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
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.