So I have made a program which copies some files from System32 on 32 bit machine while SYSWOW64 on 64 bit machine to another destination after the User accepts it. I have added an administrator manifest in it so it asks for admin privileges before starting. Is that necessary? I don't want to cook the Users brain by asking him every time for admin privileges. So does copying something from the above two locations need admin privileges?
Regards,
Reading files does not require admin permission, though writing does.
There are a number of implications of this:
If you install Apache, you can read the httpd.conf with notepad but saving fails unless you disable UAC.
You can copy a file from a system directory, but you cannot save a file to a system directory without asking via UAC.
BTW this is one of my biggest issues with UAC -- it means that things behave strangely and that writes can fail after you have already made changes, which can be very annoying if you come from a UNIX background and expect it to work something like sudo....
Related
I've written a Win32 program that at regular intervals retrieves content from a dedicated server on the internet.
Sometimes the Win32 program itself needs to be updated. What I do is exit the said program and run a download-program which replaces the main exe I need to uopdate. This works for users running in Administrator mode but not other mode that has sufficent rights for most tasks. The program runs on it own directory which is not under "c:\Windows\program files\".
I've set a manifest file to no avail.
Is there a workable workaround solution for this (any)?
For security reasons you cannot place files in Program Files without admin rights. If you would be able to this you could in theory change Windows files and place malware as well.
Same goes for Linux and OSX systems.
However you could prompt the user for an Administrator password and gain the admin rights in that way.
You need your updater program to have admin rights. You achieve that by adding the requireAdministrator option in the requestedExecutionLevel section of the application manifest. You said that you have tried this to no avail. Well, you must have got something wrong because this is the solution. You just need to persevere until you get the manifest correct.
I presume that when you say that the [program is not under the Program Files directory you refer to the updater. If the program being updated is not under the Program Files directory then there would seem to be no obvious reason that the updater needs admin rights. If that is so then you need to investigate further.
Important! Because an activated User Account Control (UAC) on your
system some functions of XAMPP are possibly restricted. With UAC
please avoid to intall XAMPP to C:\Program Files (missing write
permissions). Or deactivate UAC with msconfig after this setup.
I was searching for any farther information, but nothing found. Does anybody know what exact problems might I have if I would install XAMPP on Program Files with enabled UAC (especially on Windows 8/8.1)?
Apache2, for example needs write access, which wont be granted by Windows for any program trying to write into the program files directory. Obviously for security reasons, otherwise a program could manipulate other programs.
I don't know exactly, why Apache needs write access, but I think it is because of the log files, which are contained in some sub-directories of the installation
Based on the assumption that standard users can't write directly to ProgramData on Vista and later, I'm creating a directory inside it and giving all users full control of that for my program's use. It works fine, but during testing I tried to run some test code as Guest (which is supposed to be restricted) and it successfully created the directory and granted the intended rights. I wasn't expecting that to work, when I've seen so many stories of that kind of thing not working. The same thing happens if I create a standard user account and run the program from there.
Has anyone else seen that behavior? It's not being virtualized, and it appears that the UAC awareness tweak to the program's manifest (I'm using VS2005 here) is working because I get errors when I try to write to System32 instead of a file in VirtualStore.
I would just let it go and count my blessings, but this software won't just be running on my machine and I'd like to make sure it'll work in other environments.
Users are able to write to the ProgramData folder, because rights to create files and folders are granted to Users by default:
The same is true on Windows 7. Likely also true on Windows Vista.
The default permissions allow non-admin users to create directories in ProgramData, so the observed behaviour is as-expected.
I have been unsuccessful getting a Java WebStart application that should have AllPermissions to write a file to Windows/System32 on Vista or Windows 7. While I don't believe this is possible, perhaps there is a way to lower the integrity level of this folder to Medium?
I am getting desperate and am not above insane registry hacks to make this happen. We have a production app that runs fine on Windows XP however a new prospective client is unbending in their determination to ONLY maintain Windows 7 or Vista workstations.
I appreciate any help or suggestions and would especially love to hear from anybody if this is impossible. Please no comments on how insecure and dangerous this can be, I am aware of the risks.
The proper solution is to have the required DLLs placed in the system32 folder from your installer.
Your MSI installer will know how to prompt the user to elevate to administrator, so you then have permission to add your files to the users System32 folder.
You will not be able to modify files in the users's System32 without them being (or elevating to) an administrator; that's a fundamental constraint of the secure operating system.
First of all, as the author of CHML -- the app you mentioned -- it's unfortunately not a great idea to lower the integrity of the Windows folder (as you've seen).
That said, there IS a way to get things back the way you want -- several, actually, but the easiest way is to
1) Create a bootable WinPE CD or USB stick
2) add my chml.exe executable
3) Boot your system
And at that point you could use chml to re-raise the integrity level. It works because under WinPE you ARE running as System, and can raise your IL. (The docs (ahem) DO mention this. :-)
I figured out how to do this for Vista but am really unnerved by what I have done.
There is a free program out there that you can download that will give you the ability to change the integrity level of a folder. http://www.minasi.com/apps/
Using this program however from the commandline will give you Access Denied when attempting to change System32 to Medium integrity. This is because the Administrator does not have explicit rights to this directory.
This is where it gets really scary, to give yourself Full Control on System32 you have to make Administrator the Owner of that directory. The current owner is TrustedInstaller originally.
So, I changed the Owner of System32 to Administrator, Gave Administrator FullControl, then used chml from an Adminstrator command prompt to give System32 Medium integrity.
I now wonder what the consequences could be of System32 having a different Owner, however if Vista allows you to do this out of the box then it can't be that bad. Right???
This is a strange one to me. Let me list the setup:
Application with a manifest (ie: wont get pushed to virtual store)
UAC is turned on (can't write to other program files directories, or other areas, and uac prompt appears)
Can write to "c:\program files\%app_name%\%directory%\" both from within my application (not run as admin) as well as a non admin command prompt
Can not write to "c:\program files\%app_name%\%directory%\%subdirectory%\".
Any ideas? Are there hidden permissions or registry settings somewhere? Could it be that this directory was created when UAC was off, so now its fair game? Could it be that this directory was created in a time of XP, and its fair game?
It makes sense to me why i can't write to the other program files directories and the subdirectory. However I have no idea why i am actually allowed to write to the %directory%?
Side note: If I move the %directory% to another area (appdata), I still can not write to the subdirectory (confused).
Let me know any ideas you may have or anything I can check.
Thanks
EDIT: Arr, sorry, I skimmed your post a little too fast, looks like this is a non-issue!
Have you looked where the written files are actually going?
Vista has a feature where files written into Program Files folders by applications get redirected to a local per user store. This store is located at %userprofile%\AppData\Local\VirtualStore
This is to allow legacy applications which wrote per user settings to Program Files to still operate correctly, also allowing multiple users to use the program without conflict.
There's a button in explorer called 'Compatibility Files' which will take you to this user store.. perhaps your writes are ending up there?
I'm not sure why you cant write to the subdirectory though. Security permissions?