I have another question dealing with app sandboxing. So I need access to the users' home directory and at the same time the app should be able to shut down the Mac. This requires to not using sandboxing.
My problem is that I don't know how to remove sandboxing and being able to submit the app to the Mac App Store. I think that the archives are sandboxed because I had turned it on once..
How to remove sandboxing from the archives properly?
Thanks for your help!
On Xcode 11, you can turn off Sandboxing by removing it from the Signing & Capabilities tab:
If I understand what you are asking correctly, you'll need to remove the entitlements.plist from your project and make sure that the Summary view of your target in Xcode has sandboxing turned off:
As Derek Wade pointed out, you can make an App like GarageBand X (which behaves obnoxiously with third party plugins like Amplitube due to Sandboxing) NOT run in a sandbox by editing the binary itself with a HEX editor like HexFiend. Look for:
<key>com.apple.security.app-sandbox</key>
Immediately following that bit you'll see the true tag, which as suggested I switched to 'fals' (no extra bytes) and now GarageBand will happily interact with third party VST plugins. Huzzah.
I found if you go into the .app package, under Contents/MacOS, there should be a binary file that matches the name of your app. Copy that file to your desktop. Edit the desktop copy of the file with TextEdit. You should find within the file, the text representation (xml) of the Entitlements for the app. Find the Sandbox entitlement flag (usually set to <true/>) and change it to <false/>. You will have to unlock the file when editing. Save the file (located on the desktop). Rename the original file in the .app package (i.e. append .old to the filename). Copy the desktop file back to the .app Package location (you may have to authorize it). This should remove the sandboxing.
You cannot remove Sandbox if the user ran you application via Sandbox.
That's the whole point - don't you think ?
Related
I made a pkg installer and I'm trying to debug the codesigning issue where GateKeeper has put the quarantine flag on the installer.
This quarantine translates to the permission denied when the application through the CLI, or when double clicking, or when right clicking > open:
It does this only when the installer gets downloaded. I think I have figured out why the installer gets quarantined by GateKeeper, but the only way I can test this is by uploading it and then downloading it. This is slow, and I would like to run GateKeeper checks without wasting time uploading to the internet.
I read somewhere that zip`ing the file and unzipping it might work, it doesn't.
The quickest solution I came up with is to drag and drop the file onto a web browser and re-download it from the browser. This doesn't use any internet. It still passes through GateKeeper since the quarantine flag is re-added to the .pkg file.
Even Apple doesn't suggest this:
Quarantine a copy of your app. You can do this in either of the following ways:
Email the app to yourself and use the copy that Mail downloads.
Host the app on your own local or remote server and use the copy that Safari downloads
I have an app that installs a DriverKit system extension when it launches.
If I then drag this app to the Bin from /Applications then I am prompted about that the app also manages a system extension and that the system extension also will be removed.
I would like to have an uninstaller that removes the app. I have tried to remove the app in the uninstaller with rm -rf, but then the system extension is not removed.
I have also tried the trash terminal utility (can be installed with brew install trash) to check if something similar could be used from the uninstaller, but without luck.
Is there a way to programmatically remove an app and also the system extension that the app installs.
Good question! I don't have a fully baked answer, but enough suggestions to try that they won't fit in a comment, so here goes anyway:
Try using Cocoa APIs for "trashing" files. This answer gives a good rundown. I don't know how this will cope with the system extension confirmation though.
If you definitely want to pop up the confirmation dialog, using AppleScript to tell the Finder to delete the file is a great approach. I can confirm the solution given in this answer works but it will show the confirmation dialog, which may or may not be what you want.
You can uninstall a system extension (including a dext) using the systemextensionsctl uninstall command. Unfortunately, this will always pop up an authentication dialog, even if you run it with root privileges. But depending on what you're doing, that might be preferable to the above.
I am distributing my OS X application on individual USBs and, for this reason, everything must be self contained.
The app itself lets users input information and then saves this information to an existing text file (specifically an ObjectDB database). Herein is my problem.
I'd like to keep this text file inside the app itself (i.e. inside the Content folder) so it's out of the way and can't be deleted by the average user. But once the app is signed, it seems the text file can't be altered with any new information without getting flagged by Gatekeeper. Is this really the case? There's no way to store data files within apps now?
I'd appreciate any suggestions. Thanks.
Yes, you are correct. If you modify the application package, the signed package is no longer valid. That's kind of the purpose of signing a package.
Your options are to store the text file in a temporary folder on the user's computer, or to instruct your users to disable gatekeeper (don't do this).
I created a DMG .this has 640 and apache permissions. once i uploaded it to internet some extended attributes are getting added to it. Because of that when customer downloads it they are getting a pop up
"There may be a problem with this disk image. Are you sure you want to open it?
Opening this disk image may make your computer less secure or cause other problems."
I don't want quarantine attribute to be added to it.so what should i do to my dmg before uploading it to internet such that quarantine attribute will not be set.And also why this pop is not coming for other dmg's downloaded from net. I downloaded google chrome.dmg, for that quarantine attribute is not set.can any one help me out with better solution
Did you sign the entire DMG as well as the .app file? I believe this is a new requirement if you have additional files in the DMG besides the signed .app.
(Copied from my answer at Mac DMG oddity - signing and "damaged" applications)
In addition to signing the .app bundle:
codesign -f -s "Developer ID Application: Your Dev ID Here" -v "Your App.app"
you should also sign the created DMG as well:
codesign -f -s "Developer ID Application: Your Dev ID Here" -v YourProgram.dmg
I didn't put quotation marks around the dmg file path because it's less likely that you have spaces in the dmg name. If you do, don't forget to escape them on the command line, or wrap your file path in quotes.
I don't want quarantine attribute to be added to it.so what should i do to my dmg before uploading it to internet such that quarantine attribute will not be set.
Distribute it through the App Store or sign it with your Apple developer account.
And also why this pop is not coming for other dmg's downloaded from net.
The other DMGs are probably distributed through the App Store or signed it with an Apple developer account.
Here's the settings of interest:
The best you can do is distribute through the App Store (in Apple's opinion).
I settle on the App Store and Identified Developers. There's no difference between the two in my opinion - in both cases, I rely upon Apple to check the developer and binary. Where it comes from (App Store vs Internet) does not matter to me.
However, I trust some developers more than Apple's assertion. For example, I have more trust for the Wireshark folks than anything Apple has to say about an unknown developer. I would install Wireshark even if it was not signed (xattr -r -d "com.apple.quarantine" <app> to the rescue).
I don't think this is related to the extended attributes or quarantine at all. That error message indicates that the filesystem in the disk image is corrupt, probably because the image was damaged during uploading/downloading (see this previous SU question). Can you checksum the image before and after uploading & downloading it to see if it's been changed somewhere along the path? Also, using Disk Utility to verify the volume would be useful.
As far as quarantine is concerned: the quarantine attribute is added when the image (or any other file) is downloaded; there is nothing you can do to prevent this. If there were a way to avoid this, the bad guys would be using it on their malware to evade the quarantine security checks -- and Apple would consider this a bug, and fix it. Your customer can remove the quarantine after downloading the image, but this should not be necessary. (Although you may want to sign some/all of the files inside the image to comply with gatekeeper's restrictions.)
I've been playing around with an app I want to submit to the Mac App Store, and part of the functionality is simply grabbing a file the user chose by dragging or opening, and saving a modified of it to the same directory as the original file (but with a different file name).
I don't want to use a 'Save' dialog box, as that destroys the utility of the application I'm building, but it looks like that might be the only way the app would be allowed—under sandboxing requirements—to write a file to an arbitrary location (arbitrary, in this case, being in the same folder as the existing file) on the disk as a new file.
Is there any way I can approach this without disabling sandboxing? Also, if I submit the app without entitlements/sandboxing turned on today, will it be approved by Apple (supposing it passes all the other requirements), or are they already turning down non-sandboxed apps?
For your first question, no, I don't believe there is any way to write to a file the user didn't specify, unless it's either in your app's container, or (as of 10.7.3) in a directory you have a security-scoped URL for. See the documentation here. If the user specifies a file, I doubt you get permissions to the enclosing folder, but it's worth a shot.
Answering your second question, as of today, Friday April 27th, 2012, the App Store does not require sandboxing. The latest deadline given was June 1, 2012.