Writing to a file in \Program Files\ RRS feed

  • Question

  • Would anyone be able to point to a way to write to a file in the \Program Files Directory?

    I know that the first reaction from a lot of people will be that I shouldn't do that and the second reaction will be that it can't be done because I'd have to disable UAC (User account control) and I can't do that without having the right permissions in the first place.


    I can run inno and it can install a program in \Program files\xyz

    It doesn't NOT have any problem with permissions so it can CAN be done.

    When I have the program installed it would be nice to let the user press a button and get a software update from my server without having to go back to the website to download it by using inno again. I can do this easily and I have it working when I put the program in \xyz but I'd like to make it work in \Program Files\xyz which would be more standard. I working in VC++.

    Thanks in advance for any help


    Sunday, January 13, 2019 5:30 PM

All replies

  • In the typical Windows system standard users do not have write access to Program Files and its subfolders.

    An installer that creates files/folders underneath Program Files is running with elevated privileges, not as a standard user.

    An installer running with elevated privilege could modify the security descriptor for the files/folders that it creates to allow a standard user to have write access.  However, this would create a security exposure since the integrity of the related content could be more easily compromised.  Not recommended.

    Sunday, January 13, 2019 7:07 PM
  • I can run inno and it can install a program in \Program files\xyz

    It doesn't NOT have any problem with permissions so it can CAN be done.

    Not quite. It's like you see youtube videos with various tricksters walking on water or disappearing and so on. This does not mean it CAN be done, it means that you've been tricked. Smoke and mirrors. The installer actually YES runs elevated, or it gets "virtualized" and writes somewhere else.

    -- pa

    • Edited by Pavel A Sunday, January 13, 2019 9:51 PM
    Sunday, January 13, 2019 9:50 PM
  • This is not the easiest question to answer because an installer may need administrative rights for more than just writing to Program Files. Locations that you may want to write to include the registry under HKEY LOCAL MACHINE, the all users start menu under ProgramData\Microsoft\Windows\Start Menu, or the all users desktop under users\Public\Public Desktop.

    If you want to make your application insecure enough that a regular user is able to update it, then take note of two things. First, make sure you advertise this and recommend that administrative users do not run it with full administrative rights. Write it in bold flashing text or whatever, just make sure that if anyone complains you can tell them that it is quite clearly documented. Also, make sure that your application does not handle passwords, personal information or anything else sensitive. This should be obvious as to why, any authenticated user (this includes limited users) could just replace the executable with a hacked version to do nasty things.

    Secondly, if you use HKEY LOCAL MACHINE in the registry then you are still going to have to initially install with administrative rights in order to modify the security on the registry keys to allow updating by authenticated users. The same should be true with start menu and desktop icons.

    If you do it right, then you can use an updater that will update without requiring administrative rights. But to be honest, by this point, it would be easier to do a per user install of the application. While the user is able to update it, they get some protection from malicious users due to the fact that it is installed in their user profile, and the profile is protected by security only allowing administrators and themselves to write to it. This means that an administrative user should be able to run it with full administrative rights. Of course, the drawback of a per user install is that you can't share it between users, so all users on that machine will have to install and update it independently of each other.

    To be honest, what it feels like here is that you want the best of a per machine install, but with the best of a per user install. But unfortunately if you try to mix the two then you basically get the worst of both. Choose one, it will make your life a lot easier.

    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Monday, January 14, 2019 2:49 PM
  • If you decide to self-elevate the program during the update procedures, then check an example:

    The users will have to accept the elevation in the corresponding system dialog.

    Monday, January 14, 2019 3:08 PM