Bug 16927 - Signing with keychain-access-groups entitlement causes "unsafe use of @executable_path" for the bundled .dylibs
Summary: Signing with keychain-access-groups entitlement causes "unsafe use of @execut...
Status: CONFIRMED
Alias: None
Product: Xamarin.Mac
Classification: Desktop
Component: Other ()
Version: 1.6.19
Hardware: PC Mac OS
: Low normal
Target Milestone: master
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-12-21 01:44 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2016-09-26 21:59 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test case (20.79 KB, application/zip)
2013-12-21 01:44 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details
Test case version 2 (23.08 KB, application/zip)
2015-02-23 22:03 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 16927 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Brendan Zagaeski (Xamarin Team, assistant) 2013-12-21 01:44:36 UTC
Created attachment 5712 [details]
Test case

This bug is loosely related to bug 16250. In that case the `keychain-access-groups` entitlement imposed a requirement that libc.dylib had to be loaded using the full path name.

In this new case, the problem is instead that the _bundled_ native libraries (like libgdiplus.dylib) contain references to the other bundled native libraries, and these references use relative "@executable_path" references. Apparently the use of "@executable_path" is not permitted when using the `keychain-access-groups` entitlement.


## Steps to reproduce

1. Build the attached test project in Release mode. This should sign the app using a "Mac Developer" profile. If it doesn't, adjust the bundle identifier, or install a "Mac Developer" provisioning profile as needed.


2. Run the app (optionally from the command line with more verbose Mono logging [1]).

> [1] MONO_LOG_LEVEL=debug MONO_ENV_OPTIONS=--trace=E:all SystemDrawingColorTest/bin/Release/SystemDrawingColorTest.app/Contents/MacOS/SystemDrawingColorTest > output.log 2> errors.log


3. Click the "Push me" button. This will attempt to instantiate a System.Drawing.Color.



## Result

The app quits after the button has been clicked.


### From the verbose output (output.log)

> Mono: DllImport error loading library '/Users/username/Projects/KnownColorsTest/KnownColorsTest/bin/Debug/KnownColorsTest.app/Contents/MonoBundle/libgdiplus.dylib': 'dlopen(/Users/user/Projects/KnownColorsTest/KnownColorsTest/bin/Debug/KnownColorsTest.app/Contents/MonoBundle/libgdiplus.dylib, 9): Library not loaded: @executable_path/../MonoBundle/libglib-2.0.0.dylib
>   Referenced from: /Users/username/Projects/KnownColorsTest/KnownColorsTest/bin/Debug/KnownColorsTest.app/Contents/MonoBundle/libgdiplus.dylib
>   Reason: unsafe use of @executable_path in /Users/username/Projects/KnownColorsTest/KnownColorsTest/bin/Debug/KnownColorsTest.app/Contents/MonoBundle/libgdiplus.dylib with restricted binary'.



### The resulting exception message (from error.log)

I'm including this on the bug report just to make the bug easier to find. Since the root problem is really the "unsafe use of @executable_path", I don't think this exception message tells us anything else.

> Unhandled Exception:
> System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.KnownColors ---> System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: gdiplus.dll
>   at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&)
>   at System.Drawing.GDIPlus..cctor () [0x00000] in <filename unknown>:0 
>   --- End of inner exception stack trace ---
>   at System.Drawing.KnownColors..cctor () [0x00000] in <filename unknown>:0 
>   --- End of inner exception stack trace ---
> at System.Drawing.Color.get_Green () <0x00013>


## Additional note about the test project

To allow the app to be run from the command line despite bug 16250, I added the following as an "After Build" Custom Command:

> sed -i "" -e "s:libc.dylib:/usr/lib/libc.dylib:" ${TargetDir}/SystemDrawingColorTest.app/Contents/MonoBundle/config


## Version information
Xamarin.Mac 1.6.27
Mono 3.2.5
OS X 10.8.5
Xamarin Studio 4.2.2
Xcode 5.0.2
Comment 2 Yakov Lilo 2013-12-27 06:04:44 UTC
I have the same bug, but my app does not use any entitlements.

Also I have two build Configuration: Release and AppStore. Bug can be reproduced only in AppStore configuration. In Release configuration all works great!

Release Configuration:
    Linker Behavior: Link Framework SDKs Only
    Use the SGen Garbage Collector
    Sign the application bundle:
        Identity: Developer Id Application
        Provision: No Profile needed
        Entitlements: EMPTY

AppStore Configuration:
    Linker Behavior: Link Framework SDKs Only
    Use the SGen Garbage Collector
    Sign the application bundle:
        Identity: Mac Developer
        Provision: Profile(with my 2 macs: build and test machines)
        Entitlements: EMPTY


=== Xamarin Studio ===

Version 4.2.2 (build 2)
Runtime:
	Mono 3.2.5 ((no/964e8f0)
	GTK+ 2.24.20 theme: Raleigh
	GTK# (2.12.0.0)
	Package version: 302050000

=== Apple Developer Tools ===

Xcode 4.6 (2066)
Build 4H127

=== Xamarin.Mac ===

Xamarin.Mac: 1.6.27
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2013-12-30 14:11:56 UTC
@Yakov Lilo:

In fact, Xamarin Studio will automatically add a few default entitlements when signing with the "Mac Developer" profile even if you don't specify an `Entitlements.plist`. As I understand it, this is done to conform to Apple's requirements for apps that are signed with a "Mac Developer" provisioning profile. The discussion on [1] might also be helpful.

> [1] http://forums.xamarin.com/discussion/10511/embedded-provisioning-profile-not-valid


You can double-check the entitlements on your signed app using the `codesign` tool from the command line. For example, the following command will print out the entitlements for MyApp.app:

> codesign -d --entitlements :- MyApp/bin/AppStore/MyApp.app
Comment 4 Yakov Lilo 2014-01-02 02:30:07 UTC
@Brendan Zagaeski:

You are right. There is keychain-access-groups entitlement.
Thank you for explanation.
Comment 5 Yakov Lilo 2014-01-31 06:16:16 UTC
Is there any workaround?
Comment 6 Brendan Zagaeski (Xamarin Team, assistant) 2014-02-17 17:41:17 UTC
## Updated steps to reproduce

As of Xamarin Studio 4.2.3, the test case no longer shows the problem by default because the build process no longer merges the Keychain Access Groups entitlement from the provisioning profile.


To reproduce the problem now, it is necessary to add two additional steps before building and running the app:

1. Ensure that you have a wildcard Mac provisioning profile available (and also installed under "System Preferences -> Profiles"), and then set the provisioning profile to "Automatic".

2. Open the Entitlements.plist file, then under the "Source" tab add a new "Keychain Access Groups" entitlement, and set the string to be the wildcard Application ID for the provisioning profile. The string will look something like "ABC123ABC1.*".

3. Build and run the app.

4. Click the "Push me" button.


## Problem now resolved, except when the app requires Keychain access?

Many apps that would fail with "unsafe use" errors before should now work by default when compiled with Xamarin Studio 4.2.3. As long as an application does not require access to keychain information, it can omit the keychain access groups entitlement entirely, and there won't be a problem. What's more, as far as I've seen, it looks like the Mac app store does not have any requirement to have this entitlement set.

On the other hand, if an application _does_ need access to keychain items, it will still need the keychain-access-groups entitlement, and will still hit this bug.
Comment 7 Brendan Zagaeski (Xamarin Team, assistant) 2015-02-23 22:03:30 UTC
Created attachment 9993 [details]
Test case version 2

Since this bug is quite old, I'm updating the test case and the version information.

Today's tests indicate that the bug is unchanged on the Xamarin side of the problem. But on the Apple side, OS X 10.9.5 and higher have a different behavior compared to OS X 10.8.5. In the newer OS X versions, the app takes a long time (on the order of 70 seconds) to complete the first button click, but after that the app works quickly, even after it's rebuilt.


## Steps to reproduce

Same as in comment 6.

Be sure to run the app on OS X 10.8 to see the "unsafe use" error. (You can build the app on any OS X version.)

I re-created the test case from a fresh template app using the latest Xamarin Studio and Xamarin.Mac versions. I included a placeholder "Keychain Access Groups" entitlement in the `Entitlements.plist` file.



## Results on OS X 10.8

The results are the same as in comment 0 (except that error message has moved from stdout to stderr due to a newer bundled Mono version).

### From the verbose output (errors.log)

> SystemDrawingColorTest[3217:707] info: DllImport error loading library '/Users/macuser/Desktop/SystemDrawingColorTest.app/Contents/MonoBundle/libgdiplus.dylib': 'dlopen(/Users/macuser/Desktop/SystemDrawingColorTest.app/Contents/MonoBundle/libgdiplus.dylib, 9): Library not loaded: @executable_path/../MonoBundle/libglib-2.0.0.dylib
>  Referenced from: /Users/macuser/Desktop/SystemDrawingColorTest.app/Contents/MonoBundle/libgdiplus.dylib
>  Reason: unsafe use of @executable_path in /Users/macuser/Desktop/SystemDrawingColorTest.app/Contents/MonoBundle/libgdiplus.dylib with restricted binary'.



## Results on OS X 10.9.5 and OS X 10.10.0

`libgdiplus.dylib` loads successfully after the button press, but then the app takes roughly 70-80 seconds before it finally updates the text field to show "Color [Green]".

Based on a quick glance at the thread back traces in `lldb`, and also based on a `.hang` report generated by force-quitting the app during the pause, it looks like the app is making calls to `libfreetype` (as part of `GdiplusStartup()` and `FcInit()`) during this time.

It also appears that OS X is caching some sort of information for the particular app bundle identifier during the pause. If you rebuild the app _without_ changing the app bundle identifier, the button press completes quickly. But if you rebuild the app and _do_ change the app bundle identifier, the first button click again takes 70-80 seconds to complete.

As with the problem on OS X 10.8, this long pause does _not_ happen if you remove the "Keychain Access Groups" entitlement. That said, perhaps it would still be best to split this second problem into its own bug report in case it doesn't have the same underlying cause as the original problem. I can do that if needed.



## Additional comments

The build process does do something new in Xamarin.Mac 1.10 and higher: it code signs all of the bundled `.dylib` files instead of just the outer `.app` bundle (17 signatures in total vs. just 1 in Xamarin.Mac 1.8). But apparently these signatures do not have an effect on the particular problem described by this bug.



## Version information

### Build system, OS X 10.9.5

=== Xamarin Studio ===

Version 5.7.2 (build 2)
Installation UUID: 2c0ea975-8f73-4920-8414-3e9ae359fbf4
Runtime:
	Mono 3.12.0 ((detached/de2f33f)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000076

=== Apple Developer Tools ===

Xcode 6.1.1 (6611)
Build 6A2008a

=== Xamarin.Mac ===

Version: 1.12.0.8 (Business Edition)

=== Build Information ===

Release ID: 507020002
Git revision: d6231e6325f274cea59da478410f561312c5b401
Build date: 2015-02-17 19:04:38-05
Xamarin addins: b212fd66838b0d6e2435966e541e66ab9c988698