I have an add-in in Excel that needs to store some data in the HKEY_LOCAL_MACHINE registry. because of the UAC control in Windows Vista and earlier versions, I added a manifest file. But it is just not working. I even added the manifests in each of the projects of my solution. I have 5 projects in my solution (3 VB projects, 1 c++ and 1 deployment).
I am using VS2005. I added the manifest file to the project (with the requestedExecutionLevel set to "requireAdministrator" and embedded the manifest using mt.exe in a post-build command.
Even with that, I am still getting an access denied to the HKEY_LOCAL_MACHINE. The only thing that is working is when I start Excel as "Run as administrator".
Any clue what the problem might be? Thanks.
Manifests in DLL do not affect the execution level of the application, in this case it's excel.exe.
Here are the options you have:
to run Excel as administrator;
to modify the add-on to write to HKCU rather than HKLM.
If you need to store data available to other users, consider using ProgramData folder (CSIDL_COMMON_APPDATA or FOLDERID_ProgramData). Then your add-on creates a subdirectory inside ProgramData and modifies its permission so that this new directory is writable by anyone (by default, only the user account that created the folder has write permissions, other users can only read).
There are some other options:
You can write a service that your add-on will communicate to write data into HKLM but it's not.
You can create an elevated COM object which will write the data into HKLM.
Although users don't expect Excel to require elevation when run, therefore consider changing your logic so that your add-on does not require elevation at all.
Related
I have in hands a third party msi installer that requires to be executed by an administrator. Im trying to change that so it could be installed by a regular user.
I managed to open it with installshield and changed some obvious settings like:
"Require Administrative privileges"
But in your perspective is that even possible? I´m having a hard time changing settings and configurations and until now i´m not having any success.
Im working with InstallShield 2013 Professional and if it is possible, in wich settings do you think i should be focusing?
For instance, running as regular user im now having a 1925 error.
"You do not have sufficient privileges to complete this installation for all users of the machine"
And i feel if i correct the error, others will appear.
Thank you guys!
It's highly unlikely you can do this because it depends on too many things in the MSI package that can change the system. Any files going to restricted locations (program files, common files etc) or changes to HKLM registry keys will require elevation. MSI installs don't violate security - they don't allow a limited user to change areas of the system that are restricted.
If the environment has group policy/Active Directory you can arrange for the MSI to be deployed from a central location via Group Policy, that's the way people get around this. Otherwise on UAC systems the MSI may offer an elevation prompt that allows admin credentials to be entered.
Otherwise the vendor needs to create an install that can be used by limited users.
Well, Yes i need administrative privileges to write to locations that are shared by multiple users. In the filesystem, this means folders like \WINDOWS or \Program Files. In the registry, this means all of the hives which aren't per-user. That´s ok, i don´t need any of this.
Therefore, i thought it could be possible to change the filesystem to something like [userprofile] and rewrite the program to only use the HKEY_CURRENT_USER.
But i suspect it could be more to it than only this.
I have developed an application in Visual Basic.net. When I install this application to a ProgramFiles/[Appname] folder, and I create a file that is saved in the same folder (a settings file, created from in the application), the file is not visible, yet the application can still read it.
Where is this file saved?
On Windows Vista and higher, writing to the Program Files directory requires administrative privileges. Your file is probably being affected by virtualization (a redirection of the write operation) to the virtual store. You can find it (in Windows 7) in C:\Users\<username>\AppData\Local\VirtualStore.
The obvious solution is not to try to save the settings in the wrong location in the first place. Your app should create a folder under %APPDATA%, and write it's settings there instead. This answer to a related question can provide some links that might help.
I have full admin privileges on my Windows 7 machine but when I run my application which creates a file on c:\ drive I get error code 5 (Access is denied). I know windows 7 doesn't allow creating files in protected areas like c drive and program files and file explorer brings up 'administrative' message box if I copy a file there from somewhere else after which it does allows but can my application obtain write level access?
In my application, user gets to pick the folder where they want to create the file so if they choose c:\ drive s/he will obviously get this error which is not desirable.
void CTestDlg::OnBnClickedButtonCreate()
{
CFile f;
CFileException e;
TCHAR* pszFileName = _T("c:\\test.txt"); // here i am hard coding path for simplicity.
if(!f.Open(pszFileName, CFile::modeCreate | CFile::modeWrite, &e))
{
TRACE(_T("File could not be opened %d\n"), e.m_cause);
}
}
As far as I have researched it seems I can't by-pass the UAC dialog which is fine but my application don't even present it (which is understandable as well) but what are my options?
I see my only option is to detect this in my own application if this is Windows 7 OS and than check for file path before creating the file and present a more user friendly message 'windows 7 doesn't like you to create file in this folder, choose a different folder or go back to xp'. Is this scheme the way to go on Windows 7? Is there any other way?
As Kolink noted, your application needs to run with administrator privileges. In order to do that automatically, embed a manifest as explained here.
EDIT: For VS2010: Project Properties > Configuration Properties > Linker > Manifest File Change the 'UAC Execution Level' to the desired value.
Either don't try to write to protected areas, or require that your application be run with permissions (right-click => Run as Administrator).
I know I don't like random files appearing in my root - I like my files organised.
If it's the user who provides the path, then you should inform them that the file cannot be saved to this location and ask to provide another name.
Usually the shell, GetSaveFileName function, checks whether the new file can be created in the selected directory before returning, see flag OFN_NOTESTFILECREATE in description of OPENFILENAME structure.
Another option is to handle such situation and to show UAC confirmation yourself. But this solution requires much more effort than it's really worth. You can't elevate the current process, so the operation of saving the file to a protected area has to be implemented in another process. At the same time your current process has the data to be saved, so you'll have to implement the communication between the two processes. Read Designing UAC Applications for Windows Vista for more information.
I have an InstallScript installer that utilizes dynamic file links for several components. These components contain configuration files that standard users should be able to edit. We recently discovered that when these files are installed on Windows Server 08, the permissions are set to full access for the Administrators group, but only read & execute access for the Users group. The typical install location is C:\programName.
I've tried creating new files manually as an admin (right click - new text file) in the C:\programName directory, and they are generated with identical permissions. I'm assuming that this is just the standard permission setup for new files.
Is there any way, within InstallShield, to set the permissions for dynamically linked files or the directory containing them?
I've looked for permission settings in
Organization -> Components
Application Data -> Files and Folders
but I haven't found anything. The documentation on dynamic file links makes no mention of permissions.
We are using InstallShield 2010.
Generally these permissions are a good thing; they're inherited from their parent folders. Non-administrator users (including the limited access admin before accepting a UAC prompt) should be unable to modify files under Program Files or C: so I would suggest addressing this concern in your application (for instance by using each user's Documents folder). Since you don't talk about why you need it, it's hard to say with certainty if this applies to your case.
If it turns out it does make sense to address this in the installation instead of the application, you can use the SetObjectPermissions API to set permissions programmatically.
In "Files and Folders" page right-click the file or folder, select Properties and click the Permissions button. In the "Permissions" dialog you can then right-click in the Name(s) list and use the New context menu option to add a new permission.
If the option is not available for a file, you can try setting it on the parent folder.
My application is not supposed to perform any administrative tasks, so I want a normal User account to be able to run it. Only thing is, my application reads from and writes to a database file; if the user running Windows 7 (Or Vista) installs my app in drive C, the drive's default permission set configuration doesn't allow my app to write data.
How can I allow my app to write to C:, without requiring full administrative privileges?
If the database file exists at install time you can just grant the user write access to the file as part of the installation process (ordinary users do not have this permission by default). If the file needs to be created by the program the user running the program will need modify permissions on the c drive, which is not something that I would recommend.
I'd suggest storing your db file in Documents and Settings / App data / your app / directory. It exists specifically for this purpose. Writing to C:/Program Files is not so good practice. If that's possible in your case, that is.
You need to open UAC (User Account Access) and set security slider to the bottom. Then you can access drive C: as you did in windows XP.
I decided to modify directory permissions in the setup process, so I created an .exe file that changes the permissions of its start-up path, and gives all users access to that path. I simply included that .exe file in my deployment project, and created a Custom Action that would run the file in the Commit phase of installation.
Because the setup asks the user for administrative rights when it is being installed, my .exe also enjoys administrative privileges and can modify the permissions of the installation directory.
In my .exe, I used a Process instance to run the ACL utility shipped with Windows (icacls.exe) as follows:
ICACLS.EXE [TargetDir] /T /C /grant Users:F
(Make sure that [TargetDir] doesn't end with a "\" or the call will fail.)
This gives all users full control access to the target directory.
I could also write .NET code and change directory permissions manually, but I'm a little lazy!
You may however want to inspect your environment conditions thoroughly so that what you do wouldn't become a security hole in your environment; but this was suitable for me.
I hope this helps others who faced the same issue.
The user by default should have write permissions to drive C:, if not, then you will need to change the directory you read from and write to, to the executing directory (C:/Program Files/Your App/) rather than the root of C:
You can get this by
String Path = Path.GetDirectoryName(Application.ExecutablePath);