This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Set permissions on your executable inside the project.
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Sep 15, 2009
01:31 PM
getting permission errors accessing files/directories on windows 7
so I finally got my 64-bit release built and working - sort of. Of course we are going to be releasing on Windows 7, 64-bit. My components all seem to install properly, shortcuts work, registry entries as expected. Then when I launch my desktop shortcut, I get 'Access to path xxxxxxxxx is denied.' [xxxxxx is a path created by the installer where ourt exe is located.] When our software starts, it looks for a license file. If it doesn't find it, it creates it - well, it tried and was DEE-NIDE by windows 7. Windows XP this works great. (I skipped over Vista completely. ) If I launch the shortcut by selecting 'Run As Administrator' it works just fine......but of course not only will our users NOT be running as administrator, they won't even be logged in as administrator (like I was when I encoutnered this error).
Any suggestions on how to fix this, or what special steps I need to take, or a pointer to a useful document/article would be greatly appreciated.....
Any suggestions on how to fix this, or what special steps I need to take, or a pointer to a useful document/article would be greatly appreciated.....
(12) Replies
‎Sep 16, 2009
01:31 AM
Try setting the permissions on the folder where you want to create the shortcut.
If that helps you might want to have a look at the How to set folder permissions with cacls? thread to set permissions.
Permissions can also be set from within Files and Folders in InstallShield, however we experienced that certain existing permissions are then removed,
so we resorted to using icacls on Windows 2008 R2 (cacls is for XP).
If that helps you might want to have a look at the How to set folder permissions with cacls? thread to set permissions.
Permissions can also be set from within Files and Folders in InstallShield, however we experienced that certain existing permissions are then removed,
so we resorted to using icacls on Windows 2008 R2 (cacls is for XP).
‎Sep 16, 2009
10:29 AM
You can set permissions in the executable inside your project by right clicking on it inside the files and folders view.
[LIST=1]
Select Permissions
Press "Insert to use a new user group"
Enter "Everyone" (This is a group defined by windows to specify everyone)
Leave Domain Alone
Select Read & Execute
Select OK
I would not give permissions to the entire folder unless youre application needs to write data out to those directories. Otherwise I would only give permissions to the neeeded files. This is good practice even for XP because if you have limited users on xp they can now run your application as well.
Best Regards,
Heath Morris
Release Manager ProModel Corporation
[LIST=1]
I would not give permissions to the entire folder unless youre application needs to write data out to those directories. Otherwise I would only give permissions to the neeeded files. This is good practice even for XP because if you have limited users on xp they can now run your application as well.
Best Regards,
Heath Morris
Release Manager ProModel Corporation
‎Sep 16, 2009
10:30 AM
‎Sep 16, 2009
12:44 PM
The correct fix depends on what you can change, and what exactly the scenario is. If this is a predetermined file that you can install, then it might be okay to change permissions on that single file similar to what some of the comments above suggest. But anything of this nature is fighting the security model that Windows gives you.
If instead you can modify the program itself and don't need to write to this license file, make sure it's being opened only for read access, as a limited user shouldn't have write access to ProgramFilesFolder. If you do need to write to the file, it should probably be relocated to a program-specific folder under the user's LocalAppDataFolder.
If the data really needs to be shared across multiple users, it might be better to use the public documents folder or the CommonAppDataFolder (ProgramData folder). However for this there's not a significant security savings, so you'd have to weigh the cost of the change over the cost of extra steps in your setup in the first (change permissions) suggestion.
If instead you can modify the program itself and don't need to write to this license file, make sure it's being opened only for read access, as a limited user shouldn't have write access to ProgramFilesFolder. If you do need to write to the file, it should probably be relocated to a program-specific folder under the user's LocalAppDataFolder.
If the data really needs to be shared across multiple users, it might be better to use the public documents folder or the CommonAppDataFolder (ProgramData folder). However for this there's not a significant security savings, so you'd have to weigh the cost of the change over the cost of extra steps in your setup in the first (change permissions) suggestion.
‎Oct 01, 2009
09:12 AM
Thanks all for the ideas. Will review and try. Wish the Windows 7 webinar was LAST MONTH!! waiting til the 13th ro move forward on several items is killing us......Sorry it took me so long to review. I thought I would get an email when someone responded to my question but I didn't....
‎Oct 01, 2009
09:30 AM
Right clicking on the file in the files and folders view - or any view - does not offer a Permissions option- only: Add, copy, delete, refresh, opencontaining folder, and properties. So I still don't understand how to make my exe run for all users. (the issue isn't just running via the shortcut, its also running it from Start > Programs. Please remeber this is an InstallScript project.
As for the access denied, the file is not installed. It is checked by the exe and created if it does not exist. Sounds like the developers need to get the file moved to the appropriate Windows 7 location.
As for the access denied, the file is not installed. It is checked by the exe and created if it does not exist. Sounds like the developers need to get the file moved to the appropriate Windows 7 location.
‎Oct 01, 2009
11:06 AM
since the file you are trying to create is not part of the installations setting the permissions on the executable won't have any impact on the ability to write the file, but if you ever do need to know how to modify the permissions for a file you jsut right click the file in file and folders view and select properties. In the lowr right corner there is a Permissions button that will open the permissions view for the file.
The only way to correct the issue you are having is to either install a blank license file and have the permissions set to allow anyone to modify it, or to have the drop location of the license file changed to a publicly accessible location that all users would have read/ write permissions to. Either of these solutions would likely require a change to the code by the developers of the application.
The only way to correct the issue you are having is to either install a blank license file and have the permissions set to allow anyone to modify it, or to have the drop location of the license file changed to a publicly accessible location that all users would have read/ write permissions to. Either of these solutions would likely require a change to the code by the developers of the application.
‎Oct 01, 2009
11:16 AM
Post is about 2 different issues.
(1) being able to launch the installed exe without running 'as administrator'
(2) the exe not beinfg able to create the license file
For #2 - on windows XP we found that we had to set permissions on some directories that our exe used during operation. Thought maybe this was somehow a similiar incident. It is but under the much bigger UAC umbrella context so the real issue isn't permission into that directpory, its that the directory is inappropriate given UAC and should be changed by the developers.
I still don't understand what to do with the installer to have our exe run for all users.
(1) being able to launch the installed exe without running 'as administrator'
(2) the exe not beinfg able to create the license file
For #2 - on windows XP we found that we had to set permissions on some directories that our exe used during operation. Thought maybe this was somehow a similiar incident. It is but under the much bigger UAC umbrella context so the real issue isn't permission into that directpory, its that the directory is inappropriate given UAC and should be changed by the developers.
I still don't understand what to do with the installer to have our exe run for all users.
‎Oct 01, 2009
11:37 AM
You can find a lot of pointers for making an executable run with administrator privileges with search terms such as: UAC Manifest. If your developers are using Visual Studio 2008, support for modifying this manifest is built in as an option. If they're using something else (such as earlier versions of Visual Studio), it should still support the manifest but likely not quite as directly.
There are ways to make a shortcut specify the run-as-administrator flag, but they are not the correct approach. Search terms for this incorrect approach include: IShellLink RunAs.
There are ways to make a shortcut specify the run-as-administrator flag, but they are not the correct approach. Search terms for this incorrect approach include: IShellLink RunAs.
‎Oct 06, 2009
11:19 AM
It absolutely is, at least for most programs which do not require administrator access for their functionality. This is generally not something that you can patch over in the installer, although arguably changing write permissions on global directories can come close. Instead it normally has to be addressed in the program itself (for example as we talked about above with the location of your runtime-written license files), and then the installer can support the program by setting up the initial state.
Some programs do things which genuinely require administrative privileges. Such programs should have the proper settings in their manifest (like Process Monitor). Some only need these privileges sometimes, and those programs can choose how to set their manifest, and whether to relaunch themselves with elevated privileges (like Process Explorer).
Some programs do things which genuinely require administrative privileges. Such programs should have the proper settings in their manifest (like Process Monitor). Some only need these privileges sometimes, and those programs can choose how to set their manifest, and whether to relaunch themselves with elevated privileges (like Process Explorer).
‎Oct 07, 2009
11:56 AM
If I follow this thread, the issue is that the application is trying to create a file in the application's folder, typically under program files. A typical user does not have the rights to do this. Yes folder permissions could be changed as suggested above or the application could be marked to "requireAdminiustrator", but neither of those suggestions are really the advised solution to this problem. The design of the application should be changed to create the file in a location that the user is allowed to write too. When we started supporting Vista we had to change our applications to call SHGetSpecialFolderPath and CSIDL_COMMON_APPDATA\[ApplicationName] or one of the other paths depending on what you are doing. Applications should have taken this approach on Win XP also, but for Vista and later this is a common change. Phill