If I install my app to program files, will it always be able to create and write files within its install directory? It seems to work in a lot of different versions of windows, but are there situations where this wouldn't work?
Mainly I'm using this approach for logging. If this is not the correct approach, is there a better place to log?
Note: My installer requires Admin privileges to run and it grants Full Access to all users in the install directory.
Apps don't run as users, users run as users. If you install an app into Program Files, and let's assume you needed elevated permissions to do so, when your standard user then runs that app, that is the user that needs permissions.
App is installed with elevated permissions (user: Admin, for example)
All permissions on the AppName folder might well be "Admin:Full, Users:Read"
User runs app, so cannot change any files
At install-time, your installer will need to know which of it's own files need to be made writable to standard users, and set permissions accordingly. Of course, user-data should not be in Program Files anyway. That's what %appdata% and the user profile are for, usually.
If your app has a globalsettings.ini or whatever, that lives in "Program Files\YourApp", then while you have admin permissions (i.e. at install time) you need to grant write permission to all users to that globalsettings.ini file. Or Power Users. Or a group. Or whatever is correct for your app.
In summary, no, users do not have default write-access to ProgFiles, nor should they.
Yes, there are definitely situations where this won't work, such as when your app is running on Windows 7, or if your user account is a limited user.
We always put our log files in a temp directory or a special folder such as AppData.
Related
My installer run in all users, and it saves user information in the AppData folder.
The problem is that, when the installation is finished, an executable is launched by means of an Exec and it is launched as the administrator user, so all the session data is stored in the administrator's AppData. I want to run the installation as Admin but the last step as the current user.
RequestExecutionLevel admin
Can I launch my application as the current user? Can I keep the current user before ask for admin privilages?
The Microsoft guidelines say:
Certification requirements for Windows Desktop Apps
Apps must install to the correct folders by default
10.6 Your app must write user data at first run and not during the installation in per-machine installations. When the app is installed, there is no correct user location in which to store data.
If you have some sort of default user data/template you should install that in %ProgramFiles% or %ProgramData% and your application should copy that data to %AppData% the first time a user runs your application.
The ShellExecAsUser and StdUtils plug-ins can be used to execute your application as the "real" user on the finish page.
The UAC plug-in allows you to access the "real" users %AppData% and registry but I don't recommend this approach because the plug-in is hard to use and it really promotes incorrect behavior. You are very likely to end up with a install pattern that only works for the initial user and not other users on the same machine.
I have a windows application getting ported for Mac.In windows i store encrypted data in the registry.But when it comes to Mac im unfamiliar.
The application is licensed per PC.So all Users using the Machine will be able to use it.So in windows im storing the key in HKEY\LOCAL MACHINE
How does user access rights work in Mac? Where do i need to store the data?
This type of data is usually stored in a file in Application Support directory. If you want to store one file for all users you should choose /Library/Application Support system directory.
The directory is not user-writable, so you will have to run installer with root privileges. This directory can't be used by sandboxed apps.
You should create a subfolder in this directory and store your file inside.
For more information see The Mac Application Environment, especially Table 1-1, "Key directories for Mac apps", and File System Basics.
Edit:
Usually OS X apps don't need any installation. They are self-contained bundles that can be run from any location. Usually you keep them in Applications folder (drag it there). System wide /Applications folder is accessible for all users. There is also private ~/Applications folder in each user's home.
On the other hand apps that need to install data to system folders use installers. Installer usually copies application bundle to /Applications folder, but also handles authentication and asks user for admin credentials. Installers may also run scripts.
Maybe your license could be generated by a script during installation?
If not, you would have to generate license file on first application run. In such case, if you want to keep one file for all users in /Library/Application Support, you will have to escalate privileges and ask user for admin access. If you don't want to do that, consider storing separate license file for each user in their home ~/Library/Application Support folder.
I'm currently working on my applications installer and I'm wondering where the executable files should be installed to in Windows 7.
If I'm installing as admin my executables files get put in C:\Program Files.
If I install my product as a normal user where should the executables be put?
Thanks in advance.
Which installer are you using?
MSI runs in elevated privileges. You can install your application in program files folder
Put the files in the user folder.
This will mean that the application is only available to that user.
You should probably store that in the AppData directry, as I saw you mention in reply to #ChrisF. Remember that the user can move this directory though, so I wouldn't point to it explicitly. There is an environment variable that you can grab, that only applies to the logged-in user, which is %AppData%.
Keep in mind that putting it in %AppData%/Roaming would follow the user across multiple machines on the same Domain and %AppData%/Local would just stay on the one machine.
The executables should be under Program Files, who's precise location may vary from installation to installation. This means that the setup should run elevated. If InnoSetup makes .msi files, they will request elevation. If it makes a file called setup.exe, it will also request elevation. If for some reason the exe has a different name, like GetStarted.exe, then you should hand create an external manifest (GetStarted.exe.manifest) and put in requireAdministrator for the requestedExecutionLevel which will ensure your installer requests elevation.
Regardless of how it requests elevation, if the user doing the install is an admin (eg you) they will just have to click consent. If they are not an admin they will need to get an admin to consent for them. After that the installer will be able to write to Program Files.
If it's important to you that non admins be able to install the app then have the executables go under the users profile - but that would not be my first choice. The protection given to Program Files means that users are less likely to find themselves with messed up copies of your application if you install it to the protected area.
My installer installs the app to "Program files\MyApp", the app when running changes files within this location. On Vista, by default this brings up UAC issues.
I want users to be able to run MyApp without being admisn or fighting the UAC screen everytime they run the app. If they have to get through UAC to install the app, that's OK though still not optimal.
I thought I had this set up, but it's not working:
[Setup]
PrivilegesRequired=admin
AppName=My App
AppVerName=My App 1.0
DefaultDirName={pf}\MyApp
DefaultGroupName=MyApp
UninstallDisplayIcon={app}\bin\MyApp.ico
OutputDir=..\Installer
ChangesAssociations=yes
[Dirs]
Name: "{app}\"; Permissions: everyone-modify
Name: "{app}\redist"; Flags: deleteafterinstall;
Specifically I thought Name: "{app}\"; Permissions: everyone-modify would let normal users run it, removing UAC protection on Program Files\MyApp.
I am picking at values a bit by random, can anyone suggest some changes? Again, the aim is that once installed, normal users in non-admin accounts can run it even though files are saved in Program Files, without UAC kicking in. As a secondary thing, the installation itself should not be too crazy... a single prompt for admin password or UAC authorization.
Don't install under {pf}. Instead, install to a user-writeable location (for instance, {localappdata}).
http://www.kinook.com/blog/?p=53
You should change your app so that is saves shared data in some other folder.
Granting write permissions for any user to a folder in PF that contains executable code (exe,dll's etc) is a security issue (Evil user could modify exe file and wait for admin to run it)
Alernativly you could store the files in a subfolder in PF and only grant write access to it, that way your executables are safe.
I have a setup project that installs my app to the typical program files directly.
My app periodically saves some temporary images to the apps installation folder. It seems on Vista, the permissions are not setup for write permissions. I can change it manually in windows explorer and it works, but I would rather have the setup project do that automatically.
How can I do this?
Is there a better/more normal place to put temp images that won't have permissions issues?
It is not Vista specific, this will happen with any kind of user account that doesn't have admin privileges. Your program just can't write to folders like c:\program files\blah. That UAC disables admin privileges has been publicized for a long time now. Use Environment.GetFolderPath() to get the path to an ApplicationData folder that you can write to.
See http://msdn.microsoft.com/en-us/library/bb756940.aspx for details on UAC issues for vista. These problems can also occur in other versions of windows when running applications from non-admin accounts. You should only write data to app data or temp directories and not program files.