Death tests fail in a macOS sandbox

[wilhuff]

I'm working on porting a system that works on iOS and Linux to macOS (firebase/firebase-ios-sdk#434). We've written some death tests that work on Linux but are skipped on iOS because that platform doesn't support the mechanism. Now that we're trying macOS these tests are enabled, but failing.

Our system still has considerable Objective-C code, so on iOS and macOS we're running Googletest via XCTest, Apple's testing framework for Objective-C. We've written a bridge that allows our Objective-C and C++ tests to run together in one pass under Xcode.

This works swimmingly on iOS, but on macOS this ends up running XCTest-based tests in an app sandbox, where it fails because /tmp isn't writeable from a sandbox. In this configuration the mkstemp in gtest-port.cc at line 1115, fails with errno = 1 (Operation not permitted).

Apparently the right thing to do is use the value of TMPDIR from the environment, which will point somewhere else. On my host on one run its value looked like /var/folders/60/8r_t5wts5rn8bqz2l90c6ncm00380s/T/. Adding some logic to compute the temporary directory prior to calling mkstemp allows the death tests to succeed.

I've cooked up a PR to fix this and will submit it shortly.

[SoylentGraham]

I have just encountered a seemingly similar/same problem with a sandboxed app (crashing as TEST globals initialise)

I'm using 391ce62 and the macro has changed...
#ifdef GTEST_HAS_DEATH_TEST is now...
https://github.com/google/googletest/blob/main/googletest/src/gtest-internal-inl.h#L683

But reading the 2019 change above, and the current code... it feels like that the fix was maybe lost over the years?
Or is it a different problem

 if (original_working_dir_.IsEmpty()) {
      original_working_dir_.Set(FilePath::GetCurrentDir());
      GTEST_CHECK_(!original_working_dir_.IsEmpty())
          << "Failed to get the current working directory.";
    }

This GTEST_CHECK fails (Unfortuntely I can't see the contents of original_working_dir)

The interesting(?) thing about this... I can run my app from the terminal open myapp.app/Contents/MacOS/app and it's fine; only wrong when I used open myapp.app, which I'm lead to believe starts with cwd of / (but maybe... its blank?)

Noticed that console.app has a line

Sandbox: Studio5App(25075) deny(1) file-read-data /private/var/folders/g9/br676yyn79s45_t2xf_ffjth0000gn/T/AppTranslocation/DDF8E98A-E6FC-4096-BE38-8749254C3969

So, (and I suspect it's something with how I've got sandbox setup) but running from open or double clicking an icon, I have even more restrictions (not even a tmp dir I guess)

Another update: removing all my googletest TEST()'s (and not compiling any gtest code - which is in a dylib inside a unity app), my app does bootup; so my naiivety (no real knowledge of gtest internals) is still whether the code above is correct for sandboxing, (the temp dir stuff mentioned in the PR could be something else?)

[SoylentGraham]

Adding the macro GTEST_HAS_FILE_SYSTEM=0 to my build, also fixed the problem more formally (no changes to googletest)

I assume this isn't really the intention, and maybe the system should work under some extreme sandboxing (my particular tests work, but not explicitly using any tmp filesystem test stuff)