we are making an Application for OS X, however, when the .app is copied on another MAC, we have problems with reading and writing files
on one MAC, everything works great from the start...
the other one will not write certain files and another 2mac will not write certain different files
if i go to show application contents and wants to edit the file by myself, i get a writing permission denied
how to distribute an MAC application so there are no such issues? so all files can be read and write by the current user
does there have to be some authorization or code sign, or smth. different in this form, in addition to normal code?
thank you
It sounds like your application tries to write files within its own application bundle. The correct solution here is: DON'T DO THAT! The only time your application bundle should be written to is when it's installed or updated.
Files that the application needs to write to should be stored in the user's home folder, generally under ~/Library. See this note in Apple's dev docs.
Preference and settings files in ~/Library/Preferences/<appbundleid>.plist; use NSUserDefaults.
Data the app manages for the user in ~/Library/Application Support/<appname> (the docs say to use the bundleid, but everyone -- Apple included -- uses the app name instead).
Cache files in ~/Library/Caches/<appbundleid>.
Temp files, use NSTemporaryDirectory
If you need to share settings & files between users, that should generally go in /Library/Application Support/<appname>, except that you really shouldn't be doing that at all.
In the past I've always used PackageMaker to create installers. An installation package can authenticate with root privileges so you can set permissions after the install. I don't have it in front of me right now but if you look around you should be able to see a Post-Installer script line. Write a shell script that manually sets the permissions of each file you have in question and then have the package execute that script after the install is finished.
You can find PackageMaker at /Developer/Applications/Utilities/PackageMaker
Related
We market an application that runs on multiple platforms, including Macintosh. On the Macintosh the software gets packaged into a .dmg file, and when installed everything goes into the /Applications hierarchy.
Some of the files in our application's hierarchy are samples that users are supposed to be able to modify in place or copy to different files in the same directory. The problem is the permissions that seem to get applied within the /Applications hierarchy prevent our application from doing such operations.
So I either need to change the install so the directories and files in question within /Applications allow modification, or I need to segregate the sample files to a different location on the disk where they can be modified.
I've tried making sure the permissions on the files allow writing at the time the .dmg file is pulled together, but then when the product is installed the permissions get changed to more restrictive ones that don't allow file modification or copying.
I've been able to modify the packaging so the sample files get installed to a different location, but so far I haven't been able to find a suitable area on the Macintosh disk to put them so modification is allowed. I haven't been able to figure out how to tell the packaging that these sample files should be installed into the installer's home directory.
Anyone have any suggestions? I'm afraid I'm a bit of an Apple novice. The procedure to build the .dmg file employs a Makefile that invokes commands like pkgbuild and productbuild. The productbuild command uses a --distribution qualifier that references a .xml file. There don't seem to be any scripts invoked.
My application is starting up on boot, because it's registered in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run.
I can't change that right now, but I'm clearly running into permission problems, that prevent me from creating files in some folders.
My application runs fine when started manually by the user (without admin permissions). But it can't create files when it is started automatically on boot.
So my question is: What permissions exactly does an application have, when it is started automatically? Is this documented somewhere?
I just read somewhere that it might run as a Non- or Least-Privileged User. Still, I'm wondering what permissions they might have, since I don't find this well documented.
I'm running VS2017, C# .NET 4.0, Windows 10 1803, if that's important.
An application registered under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Both cause a program to run when a user logs in. The program runs with the permissions of the user that is logging in.
I had a similar problem. I fixed it by checking the path used to write the target file. First, I use only the target file name. In this way, the system uses the directory path from where you launch the app. (I don't know where that is.) Then, I used the full app .exe file name, including file path, minus the .exe's file name, thus getting the app's .exe file path. In this way, I can be sure where the app writes the target file. (The app's .exe directory.)
For example, c:\myfolder\myapp.exe - myapp.exe = c:\myfolder\.
Using:
SQLScript1.Script.SaveToFile(ExtractFilePath(Application.ExeName)+ FormatDateTime('yyyy_mm_dd_hh_nn', now)+'.dat');
Previously, I had done it the following way:
SQLScript1.Script.SaveToFile( FormatDateTime('yyyy_mm_dd_hh_nn', now)+'.dat');
...and it fails only at startup. If I run the app by double-clicking the exe file, it works fine.
I'm deploying a .NET application with VS2010. My application creates .txt file in the logs folder in the same directory with .exe:
app.exe
add.exe.config
logs (folder)
I used setup project to create a MSI installer. When I installed in the client machine C: drive or any drives I have no problem to create the .txt file, but when I installed in C:\Program File\myAppFolder or C:\Program File(x86)\myAppFolder I cannot to create the .txt file.
It is a poor design to write to install location for your application. It is better to write to the ApplicationDataFolder. The ApplicationDataFolder is under the user profile and the application will have access to write there when run as that user. #Ken White provided a very good pointer to an existing StackOverflow answer about this.
If this is a legacy application that must write to that folder, then you'll need to modify the permissions on the log folder such that all users can write to the folder. This is possible to do with the Windows Installer (aka: MSI) but I'm not sure that the Visual Studio setup projects expose it. The WiX toolset definitely supports doing such things.
An old post but I needed to do similar recently so I guess it is still valid! While I don't advocate bad design, in the real world sometimes we have to bend to requirement.
Writing to the application folder is possibly under Win7 and it is possible to set this up via an installer class in an MSI created by VS2010. You just need to give a relevant group (suggest either the "Users" group, or if you want to give more control over who gets what, supply a selection screen) Write-Data access.
Using DirectoryInfo on a path you can then get the security data from GetAccessControl.
When you have your Group known, get the SID for the group and AddAccessRule also supplying the required ControlType value.
Then set the access control on the DirectoryInfo object (SetAccessControl) using the security data object.
You can get the SID from the Groups principal object if you do a search with PrincipalSearcher.
Hope this helps
paul
This generally all depends on:
Whether your app requires to be run as administrator for other reasons and..
Whether your app is provided for limited users.
If the app requires elevation for a bunch of other reasons (and not just updating files in restricted locations) then the normal way is to have an elevation manifest embedded in your app. This isn't a good thing from the security point of view, but if you absolutely need admin privilege then this is the way to do it.
If the only operation requiring elevation is updating/creating data in the Program Files folder then don't put the file there. Every case of this that I've seen has been lazy programming where the code just refers to the file name and consequently it goes in the Program Files folder (more accurately in the same folder that the app runs in). The cure for this is to put the data file in the correct location (such as User's Application Data folder). As Rob Mensching says, you should alter the permissions on the install folder only if this is a legacy app that you cannot change.
I am creating a WIX installer project. During one managed customized action, I need to create a file (other than the deployed files specified in the components of WIX) in the installation folder, which by default is the Program Files folder. I am experiencing the "Access denied" problem in Windows 7. After some searching, I found out that people say it is not advisable to create files into Program Files folder. Instead, try to create files into for example AppData folder. For example, see this link:
C# Access denied to path in a Windows Application
But my question is, the generated file is crucial to our SW, so it must reside in the installation folder. Isn't it the target of SW installation, I mean, to create file in most of the cases Program Files folder? Does it mean the only files should be added into installation folder, during the installation, are the deployed files (basically the targets of XCopy)?
My file can't be made deploy-able in the WIX, i.e, it can't be made ready before the installation. So what's the proper way or best practice to handle such situation: a file must be generated during the installation, into the installation folder. It is not some log file that I can put somewhere else. I tried to create a Permission element in WIX for the INSTALLADIR, although it seems to be against the rule mentioned in the link, but it still failed. Thanks!
UPDATE:
Based one MichaelUrman's commen, some more information. The generated file is needed after the SW is installed and necessary during normal launch of the SW. And I think it needs to be modified during normal use after the installation. And as I mentioned my a comment to #caveman_dick answer, my CA is actually in commit phase, I don't know whether there is any difference between it and normal deferred CA
Set the custom action to Execute="deferred", that will run the command elevated and should give it the required permissions to create the file.
Since you need to update that file from the main application, and I'm assuming your application does not require elevated privileges, you have three options.
The first is the worst: without a manifest, your executable's attempts to write to the Program Files folder will typically result in it being redirected to the Virtual Store (see File Virtualization). It sounds like this isn't happening in your case, so you can't use it.
The second option is to modify the application to store this in an appropriate location such as the ProgramData folder, or Common Documents, or (if appropriate) a per-user location under LocalAppData. This is typically the best approach, but has the highest development costs.
Finally the third option is to create the file and change its permissions (or in some cases to change the permissions on the folder containing the file), allowing limited users to modify this file. See LockPermissions or MsiLockPermissionsEx for the Windows Installer way to approach this. Change the permissions on as few files or folders, as restricted as possible, to keep the system as safe as possible if you go with this option.
We have an application that we're porting to Mac OS from Windows. Once installed, the user can customize the functionality of the application by editing certain approved "data files" with a text editor. Once saved, the application can be reloaded to compile and load the contents. A core part of the program is the editing and sharing of these data files, and the program provides a friendly interface to allow the user to edit them.
On Windows, these folders are located under a standard folder, accessed through a shell constant, that our installer makes accessible to all users. Once installed, any user can run the application and edit the data files it uses.
What is the equivalent folder to use for the mac? Is there somewhere we can put stuff that is accessible to all users normally, or do we have to flag it as "all users can access" somehow?
Edit: A couple of users have suggested /Users/Shared. Aren't files in /Users/Shared still limited somehow to the user who created them? I remember trying to copy files between accounts in /Users/Shared, and I had to "take ownership" of the files in /Users/Shared before I could do anything with them.
Read this document. It has a section on where to put application files. I doubt /Users/Shared is the right directory for what you want to do; a subdirectory within /Library/Application Support/ is probably more appropriate. Remember, though, that non-admin users will not be able to write there by default. In that case, you can fall back to using the corresponding directory in the user's home folder.
Don't hardcode paths to special directories. Rather, you should use the NSFileManager methods URLsForDirectory:inDomains: or URLForDirectory:inDomain:appropriateForURL:create:error:, or the Folder Manager from Carbon if you're not using Objective-C.
/Users/Shared on a Mac is a folder available to any user. Hope this helps.
Use /Users/Shared/your_application_name .