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.
Related
My MFC app usually runs with admin rights, however, there is one operation which needs admin privileges (activation of the software where the status must be saved to HKLM).
For now, I created two .exe files: The ordinary app and "Activation.exe" which must run as admin and has requestedExecutionLevel=requireAdministrator in the Manifest. The activation is started with a button which makes ShellExecute(Activation.exe).
However, both applications share lots of code so I would like to merge the two exe into one exe. But how do I make sure then that specific parts of the code are executed with admin privileges? This method should/must be compatible down to NT4.
One idea is to integrate the functionality of Activation.exe in the main exe using a switch (e.g. "myapp.exe -activate"). A small bootstrapper makes sure that it can only run as admin (requireAdministrator in Manifest) and does nothing more than ShellExec(myapp.exe -activate). But is this really the best way?
I don't know if it's the best way (no-one answered) but I did that now :) The bootstrapper has just requireAdministrator in the Manifest and does a ShellExecute to the main executeable with switch "/Activate" ...
I would typically use a call to ShellExecuteEx with a verb of runas to launch any executable as administrator, even if it's manifested asInvoker.
Note that on systems where UAC has been disabled, the resulting launch may not receive administrator privileges; I believe this caveat also applies to the approach of launching an exe manifested requireAdministrator.
We have an application that is part standard EXE and part WinService EXE. The standard EXE is spawned by the Run section of the registry and comes to life at login under the credentials of the user who just logged in. The WinService EXE is set to Auto Run and therefore is always running and is running as LocalSystem (essentially administrator).
We need these two programs to share data by writing information to XML files.
The app works fine when the logged in user has access to the installed folder (C:\Program Files\ourApp). The Standard EXE writes the data and the WinService EXE reads it without issue, all is well.
However, when the logged in user does not have access to write to the installed folder, the data gets caught up in UAC Virtualization and Data Redirection and ends up somewhere else and the WinService does not find nor cannot read it from the installed folder.
To circumvent this, we tried having both the standard EXE and the WinService EXE write to and read from %ProgramData%. This would work fine except that standard users do not have permissions to write to %ProgramData%.
We cannot use %LocalAppData% because for the logged in user that would be C:\Users\LoggedInUser\AppData\Local and for the winservice it would be C:\Users\Administrator\AppData\Local.
Is there any place left in Vista and Win7 with UAC Virtualization enabled that will allow both a Standard EXE running with only user priveleges and a WinService running as LocalSystem to talk to each other. We tried the registry but the problems are even worse. Also last but not least. We need this to work with XP without any differences in code. Meaning XP also has environment variables for %ProgramData%, %LocalAppData% etc, can it work in both.
Two ideas:
Have each app expose a WCF endpoint using the named pipe
transport, and have them talk to each other over a simple interface
of your choosing.
Use Memory Mapped Files to communicate like
you were with disk files.
I have a console application written in c#, which downloads a file to program files. So of course it needs to run as admin. This program gets called from a Win32 C++ application which almost certainly is not running as administrator
What are my options. How can I get this to work on UAC and non UAC enabled boxes ( I don't know if there needs to be separate solution in each case )
Oh and the console app is in .NET 2.0
On a machine with UAC you need to include a manifest resource to specify that you want the process to run as administrator.
On a machine without UAC you will simply have to instruct your users that they need to run it as a user in the administrators group. Almost all users of XP (the version that you will most commonly encounter without UAC) are in the administrators group so you won't encounter many problems.
I never tried it, but this can probably be done using the
CreateProcessAsUser Function.
We've got a VB6 application that reads a simple text file with a .LIC file extension. When everything is working correctly, if the file exists in the same directory as the executable, it reads it. If not, it does other stuff.
I've got a customer with Windows 7 machines, and if he right-clicks the EXE and "Runs as Administrator" it "sees" the LIC file. If he runs the EXE as a basic user, the LIC file cannot be seen.
I've had enough issues with UAC to guess that UAC is running the application from a virtual directory of some sort and that's why the LIC file isn't seen. My customer swears he's turned UAC off.
Anyone have any pointers for me? It would be great if there was a way to tell UAC "let this app do what it wants in this directory". That's out of my expertise. I've been Googling till my fingers fall off, and I can't find the right answer.
Thanks!
If you think virtualization is happening (which would cause it to look somewhere other than Program Files), give him a manifest file called foo.exe.manifest where foo is your executable name and have him put it in the same folder as the exe and the .lic file. This manifest should set the required execution level to asInvoker. This will suppress virtualization and so you can rule that out as part of the problem. He may then get access denied errors but that will help you sort out the problem.
It could also be permissions? If the user is not logged on as administrator, then your program may not have permissions to read the ".lic" file. Have you checked whether the user can open it in Notepad? Is it possible your code might be trying to open it with read/write permissions, which is even more likely to fail?
You may need to change your install so that it lowers the permissions on your apps installation directory.
I have a vb6 application. I am unable to carry out the following on a Windows Vista machine:
Register a .DLL from the Users directory
Start another .EXE
Write to a file in the Users directory.
How can I overcome these issues?
This is by design. Software is supposed to require admin rights for installation (including update/upgrades). You got away with it in XP because so many people ran as administrator. If you're registering a dll after installation, you're doing something wrong.
You should be able to do this without issue, but only with the same rights as the user that the current app is running under. What is this exe trying to do, and would a standard user normally have those permissions?
What specific folder in the user's directory? Again: a user should have write access to most of the their own profile, but not necessarily as much outside of that as you think.
You have access to write to the c:\users\ directory. Going to another users directory is a bit of a security problem that you're not going to work around.
As far as registering an assembly from a users directory... There is a directory under c:\users\\AppData\Local\assembly which you should have access to for temporary assemblies
Starting another exe is trivial... As long as it's installed in the normal \program files.. path.
It really sounds like maybe you need to reevaluate how your application works.
Some suggestions:
Move to Reg-Free COM where it can handle things (i.e. not for ActiveX EXEs, DCOM).
We'd need more information. This should be no problem unless there are permissions issues.
Users are not supposed to be creating files outside of their own profiles, CommonAppData, and application-defined locations (often on non-system drives). More information is required to give any really useful answer.