Firebird Embedded in a sandboxed MacOS App (no needs install it as a Framework) - iOS possibility too!!!

[Guest]

Firebird Embedded in a sandboxed MacOS App
Friday, January 8, 2021

For those who might not be aware, Firebird on MacOS is now relocatable, in that you don't necessarily have to install it as a Framework, this also means that you can create an embedded version out of the current installer.

 

 

And the firebird.conf file would then typically be amended for the following

Providers = Engine12
ServerMode = Classic

 
For the last few weeks Alex and I (along with a Firebird user) have been working on getting Firebird embedded to work properly in a sandboxed app that can then be deployed on the App Store...
 
To do this we had to solve issues with temp files, the use of inter process communications by the
Firebird lock manager and the location of the Firebird log file.

 

Note: adding LSEnvironment to the plist file defining new locations for FIREBIRD_TEMP and FIREBIRD_LOCK does not work.

<key>LSEnvironment</key>
<dict>
    <key>ENV_VAR</key>
    <string>value</string>
</dict>

So the first issue to be addressed was the following

macosx    Wed Dec  2 15:33:57 2020
    ConfigStorage: Cannot initialize the shared memory region
    Can not access lock files directory /tmp/firebird.tmp.YDzrhQ

It seems thats sandboxed Apps cannot to write into /tmp at all, they have to use their own /tmp-folder. We can detect whether we are running in a sandboxed environment using the following calls to the Mac security subsystem

task = SecTaskCreateFromSelf(nil),        
value = SecTaskCopyValueForEntitlement(task, "com.apple.security.app-sandbox" as CFString, nil),

Now if we now know if we are sandboxed we can use  NSTemporaryDirectory() for the location of the relevant Firebird temporary files.

Having fixed that issue, it was time to move onto the lock manager.

[FireDAC][Phys][FB]lock manager error.)
 
macosx    Thu Dec 17 17:37:00 2020
    event_init()
     operating system directive semctl failed
     Operation not permitted

According to the Apple sandbox guide restricting IPC (Inter Process Communication) is also part of MacOS sandbox implementation. After some serious head scratching we tried the following test

#include <stdio.h>
#include <pthread.h>
 
#define ER(x) { int tmpState = (x); if (tmpState) { printf("Failed %s error %d\n", #x, tmpState); } }
 
int main() {
 
    pthread_mutex_t mutex;
     pthread_mutexattr_t mutexattr;
 
     ER(pthread_mutexattr_init(&mutexattr));
     ER(pthread_mutexattr_setpshared(&mutexattr, PTHREAD_PROCESS_SHARED));
     ER(pthread_mutex_init(&mutex, &mutexattr));
     ER(pthread_mutex_lock(&mutex));
     ER(pthread_mutex_unlock(&mutex));
     ER(pthread_mutex_destroy(&mutex));

c++ test.cpp -pthread
 
In case of failure it will print error messages, on success we should get nothing. We got nothing.

For many years Firebird worked with system V IPC on MacOS which is different to many other *nixes where mutexes and conditional variables in shared memory were used instead. The use of system V IPC was caused by a lack of  for shared mutexes on MacOS when Firebird was originally ported to it. Currently (as was proved by test above) MacOS now supports such mutexes. Based on this it we decided to stop using system V IPC in Firebird and a perform a cleanup of the lock manager code as part of the effort to provide sandbox support. As a side effect Firebird should now run faster using shared mutexes.
 
At the same time as we worked on the lock manager issue we also had an issue with the firebird log file, we were not allowed to write to its normal default location by the sandbox. Because we now know we are running in a sandbox we can relocate the placement of the log file within utils.cpp
 
Supposedly using something like ~/Library/Application Support/Firebird/ should work

case Firebird::IConfigManager::DIR_LOG:
             s = "~/Library/Application Support/Firebird/";
             s += name;
             return s;

 Unfortunately it seems this workaround was removed relatively recently forcing us to resort to putting the log file within the App itself ~/LibraryContainers/Company.App/Data/Library/Application Support/Company/
 
Changing the location of the log file is relatively easy but  although this allowed the App to run and resolved the issue, it was not an ideal solution since the location of the log file is now hard coded within Firebird and is App dependent and this would mean that every time somebody wanted an embedded Firebird for a sandboxed App they would have to change the path to the log file and recompile Firebird.
 
The solution was to do away with the Firebird log file and use the OSLog framework instead, and use this to capture any messages from the database engine, so if you are running embedded Firebird in a sandboxed App you can access the Firebird log messages using the Console or a terminal command like the following

log show --predicate 'eventMessage contains "macpro.home"' --start '2021-01-06 14:00:00' --end '2021-01-06 14:30:00' --info

where macpro.home is the name of the computer. You don't need the start and end, but it does help reduce the number of messages.
 
There is an added plus from using this.

 

The OSLog framework is also supported on IOS 10+ and now that the App Store will accept dynamic libraries, this means that we should be able to compile an embedded version of Firebird for IOS that can also run sandboxed Apps.

 

If anyone is interested in sponsoring this work please contact me.  

 

This work was sponsored by kiC Gesellschaft für Softwareentwicklung mbH. Posted by Paul Beach at 6:41 AM 

source: https://paulbeachsblog.blogspot.com/2021/01/firebird-embedded-in-sandboxed-macos-app.html

Edited January 16, 2021 by Guest