How to program a sandboxed application in Yosemite - osx-yosemite

I was trying to program a simple TODO app for Yosemite with sandboxing. Apple has its tutorials for the same but they are not very elaborate. I wanted to know sandbox APIs like sandbox_init() and APIs for console logs (heard sandboxed apps use some special APIs). Could someone please point me to some open source app with sandboxing on Yosemite, so that I could see the APIs that it is using.

You don't need to use sandbox_init() etc. in order to create a sandboxed app.
Roughly, you need to understand:
Use the APIs to find well known directories and don't assume that /Users/username/Documents is the Documents folder, for example.
The app has no access to user files and must gain access via NSOpenPanel.
If the app wants to retain access it has already gained then it needs to create and store bookmark URLs, which can be reloaded during a later invocation.
If the sandboxed app spawns a child process, then that child process needs it's own set of entitlements.
Once you understand that it's normally just a case of setting Use Sandbox in the app capabilities and you're off.

Related

How to Handle iOS Settings if App Uses the Network?

I have an app, in which the user can initiate a short, asynchronous download to access data on the internet, and then the app displays that data. The app is not yet released, but I have tested it on both simulator and several physical devices. On none of them, however, I can locate the app inside the settings menu where I could, for instance, restrict its network access to WiFi only, etc.
I assumed that if my app accesses the internet, it would automatically appear in the settings menu, but apparently it is not so. Am I doing something wrong? What is the process to allow the user to access such basic settings?
I use XCode 10.3, and probram in Objective-C.
If the problem is that there's not a settings entry for your app, please keep in mind that sometimes, in order for an app to be registered, you may need to close your app and the settings app and try opening it again.
If the problem is that you don't see the standard settings for location services, cellular data etc, then you may find maddy's answer here to be helpful: Why is my iOS app forcing a Settings Bundle might be helpful.
Copying the relevant part from this answer:
The iOS 8+ settings page appears […] if the app does any of the
following:
Attempts to access data via a cellular network
Various privacy data
Camera
Microphone
Photo library
Contacts
Location
Notifications
Background data fetch
A settings page may not appear for an app if none of these conditions
have yet been met.

Handling Mojave permissions ( camera, mic & accessibility) for two instances of app in same machine

My Use case :
I have an automation framework for Mac that launches 2 instances of the same app ( same bundle id) available at different locations to simulate two endpoint cases for media calls. With introduction of Mojave permissions, when I grant permission( camera , mic & accessibility) for one instance of the app, the other instance doesn't have the same permissions.
Since the bundle id is same, is it not that providing permission for the app is carried over to both instances?
I tried pushing a system profile to provide permissions but that doesn't seem to work
Also added an apple script to continuously check for permission pop-up and click ok to it. This works for mic and camera but not for accessibility. Also when each instance is launched the permission would be asked again.
Is there a way to by default provide all access to the application by default without asking for any permission pop-ups?
Or is there any way to tweak something at the OS level to not ask for permissions at all ( behave same as <10.14) .. I tried disabling system integrity but that doesn't seems solve this issue
You need to code-sign all versions/copies of the app using the same identity.
When an app is not code-signed and the system needs to record its identity (as for permissions), it generates an ad hoc code signature. That signature, though, only matches that exact build of the app. Another copy of the app that is different in any code-signature-relevant way is not considered to have the same identity. In fact, it's likely to be considered "malicious" as it appears to have been tampered with.
If you code-sign your app with appropriate designated requirements, that enables the system to understand that two different versions of an app have the same identity and should share permissions. This is key to an app maintaining permissions through an upgrade to a new version, for example.

Monitor User App Usage From Mac OS X App

I am interested in building a Mac OS X application that requires knowing what applications the user has open and when a new one opens, all when my app is running. It doesn't have to be approved by the Mac App Store (If this violates their use terms). An example of an app that does this is the Rescue Time app.
Thank you for any answers,
Michael Truell
Don't know if you're still trying to needs this, but I did some more research on how to solve this and here is what you could look into:
To get notified when applications are opened by a user, use NSWorkspace's notification center, and add an observer for keys like NSWorkspaceDidActivateApplicationNotification. See the documentation NSWorkspace. You can also use NSWorkspace to get all running applications.
If you need to access information about a running application, you should check out Scripting Bridge, and if you don't care about App Store or sandboxing, check you accessibility api, AX

make an AIR desktop application the default web browser

I would like to make my AIR desktop browser be the default web browser on a system, how can I go about and do this ?
I would also like to know how I can retrieve the link that has been clicked (in an email for example) to interact with the application.
thanks !
As far as I'm aware this is impossible in AIR. You can associate your app with file types using the air-app.xml descriptor or by calling NativeApplication.setAsDefaultApplication() (Read about it here). Opening files after using either of these methods will trigger your application to launch with an InvokeEvent (Read Here). You can read a good tutorial for this here.
However, if I understand correctly, you also want your app to take over any HTTP requests from inside any other app. To do this you have to override the protocol default application, which requires a registry edit and (I believe) that AIR can't do that. You may be able to write an external script in C or Java to do that for you (This might help with that).

Mac app sandboxing and forkpty()

I'm looking to sandbox an app to comply with the March 1st sandboxing requirement of the Mac App Store. My app includes a built-in terminal emulator which utilizes a forkpty() call to launch processes in a pseudo-tty environment. Unfortunately, this call fails under the sandbox with the error "Operation not permitted", although the fork() call works just fine. Presumably the forkpty() call requires read/write access to the /dev/ directory to create a pseudo-tty (according to the man page). I've tried adding a temporary sandboxing entitlement (com.apple.security.temporary-exception.files.absolute-path.read-write) with read/write access to /, and I now can indeed read and write files anywhere on the file system, but the forkpty() call still fails with the same error. Does anyone know how I might get forkpty() to work under the sandbox?
My app is a programming text editor with a built-in terminal emulator and file browser, so it essentially needs to have access to the entire file system. Apart from the forkpty() problem, this temporary entitlement seems to do what I need. But will Apple accept an app with such a loosely defined temporary exception entitlement?
Thanks in advance guys. I really hope I can get this sandboxing up and running so I continue to distribute my app through the App Store.
It is impossible to implement a useful terminal emulator in a sandboxed application -- even after you add entitlements for the PTY devices, the shell ends up in the same sandbox as the app, preventing it from doing very much.