GUI 7.30rev3 for OS X has no sncgss.dyld

[Former Member]

I am evaluating SAP GUI 7.30rev3 for OS X for deployment in our environment, and appear to have run into a critical problem.

I am testing on a machine with OS X 10.8.3, with the JDK 7u40 early access java runtime.

Our site uses SNC with GSS-API/Kerberos for authentication, but the 7.30rev3 installer does not provide a SNC GSS library, named sncgss.dyld or otherwise, so upon an attempt to connect, SncPDLInit() errors out with 'Unable to load GSS-API dyld Shared Library named "sncgss.dyld"'.  The previous release we have deployed, 7.20rev4, does provide a sncgss.dyld library in the application bundle's Contents/Resources/bin/ directory.  However, the sncgss.dyld library in the 7.20 release is 32-bit only (for intel processors), and the 7.30 release is 64-bit only.  The workaround given in http://scn.sap.com/thread/1851956 to run in 32-bit mode therefore no longer applies.

That thread is almost 3 years old, now, and the other threads I could find about SNC and GSS libraries are as old or older.  http://scn.sap.com/thread/2011188 makes the interesting claim that setting SNC_LIB to /usr/lib/libgssapi_krb5.dylib is an effective workaround in the poster's environment of SAP 7.20rev5 and OS X Lion, but this has not brought me success.  Using SNC_LIB to cause SAP to use several different libgssapi_krb5 shared libraries from different versions of OS X, or even from a locally-compiled version of MIT krb5 (the system library is derived from the Heimdal kerberos distribution), only results in a segfault at runtime.  This is not surprising, given that the sncgss.dyld from 7.20rev4 only exports symbols with an sap prefix, such as sapgss_init_sec_context.  The interface for these routines is not documented, and even if an external gssapi library did provide the same interfaces, the dlopen()/dlsym() approach used by the SAP GUI would be unable to use an external gssapi library that did not provide symbols with the sap prefix.

The thread in http://scn.sap.com/thread/1851956 includes a link to a (now-defunct) ftp site where a sncgssk5.dyld could be downloaded, but I believe that the libraries available there would only have been 32-bit anyway.

I have therefore come to the conclusion that the SAP GUI 7.30rev3 for OS X is simply not usable with SNC/GSS/Kerberos unless SAP supplies a library that provides the sncgss interface.  I would be delighted if this conclusion was incorrect, and would appreciate additional (hopefully authoritative) information on the subject.  Perhaps there are plans to supply such a library in a future update?

[RMW · Accepted solution]

Hello Benjamin,

welcome on SCN and congratulations to your first post, which is quite elaborate.

In general, SAP GUI for Java does not include any SNC GSS library, it only comes with the mechanism to load such a library and call into it. It requires the library provided by a third party product instead.

Information on SNC and the certification process for SNC solutions is available at

http://scn.sap.com/docs/DOC-7837

For the state regarding Kerberos support in general, please refer to

Note 150380 - Is MIT Kerberos 5 supported for use with SNC ?

Regarding the usage of Kerberos with SAP GUI for Java on OS X:

The Kerberos implementation coming as part of OS X from Apple unfortunately is compiled with 16-bit struct alignment. SAP GSS API is compiled with default struct alignment following http://tools.ietf.org/search/rfc2744 section B.2, Internal structure alignment : "The use of compiler defaults for the platform is recommended."

Kerberos on OS X with SAPGUI for Java seems to work in case it is running in 32-bit mode because the different struct alignments are not resulting in any incompatibilities for the structs being used in common.

However SAPGUI for Java running in 64-bit mode calling into the 16-bit struct aligned 64-bit Kerberos library immediately results in a crash like what can be seen in Erik's thread. (Same happens using the GSSTEST application mentioned on the SCN page mentioned before.)

For making this work, an SNC Adapter library translating between the different struct alignments would be required. This needs to be provided by the solution provider. Apple has been informed about this issue back in March 2010, but unfortunately there is no SNC Adapter library publicly available from Apple. Please refer to section Technical Documentation again on the some SCN page and go for SAP SNC Adapter 1.1 to get more information about building an SNC Adapter library.

With SAP GUI for Java 7.20, it was possible to enforce to run it on the Java 6 32-bit VM as a workaround.

With SAP GUI for Java 7.30, Java 7 is to be used, also because Java 6 is out of support since February 2013.

Earlier revisions of SAP GUI for Java 7.30 technically allowed to run Java 6 in case Java 7 is not available. Therefore it was possible to use the same workaround like in SAP GUI for Java 7.20 using the Java 6 32-bit VM.

Starting with SAP GUI for Java 7.30 rev 3, the launcher stub is requesting Java 7 and does not fallback to Java 6 any longer. Oracle decided to provide only a 64-bit version of Java 7 on OS X. Therefore the 32-bit workaround is no longer available.

Hope this helps to understand the issue, although it technically does not solve the problem.

Best regards

Rolf-Martin

[Former Member · Accepted solution]

Hi Rolf-Martin,

When I posted this, I was hoping that I would get one of your very-helpful, well-laid-out replies, and I am happy to see that it is the case.

I guess I'm still a little confused as to whether the sncgss.dyld that is in the application bundle that we distribute internally for our site is part of the official SAP distribution or something we picked up elsewhere, but that's not really relevant to the issue at hand.  (I was brought in for the Kerberos angle; I'm not part of the SAP deployment team here.)

It's good to have confirmation that the non-native alignment is likely to be the issue, my colleagues here suspected it would be relevant.  As you note, the system Kerberos libraries from Apple are compiled with 16-bit alignment; the MIT krb5 libraries also use this alignment on that platform, so the issue is pretty universal.

Reading through the SAP SNC Adapter 1.1 zip file's README gives me a much better sense of how the SNC layer is intended to work.  In particular, there is a built-in adapter for the krb5 mechanism OID, so it should be possible (as is mentioned elsewhere in this forum) to just set SNC_LIB to a library implementing the krb5 GSSAPI mechanism, with no additional shims.  (This means that my statement about exposing API functions with a 'sap' prefix is misleading, as the core program will look for other APIs as well.)

I think there are two obvious paths forward; one is to make a custom build of a gssapi_krb5 library which has the default alignment for the platform and use that directly; the other is to use the SNC documentation/etc. to build a shim around the existing OS X gssapi_krb5 library.  I think the former will be the easiest way to get something working on a developer workstation, but is less preferable for production deployment.  I'll probably do it anyway, just so that I can say that I do have the 7.30rev3 release talking to our servers; we'll need to think more about what our actual deployment strategy will be.

I will try to report back so that others (Erik in particular) can hear what we found to work.

[Former Member · Accepted solution]

I can confirm that building a GSS-API library (and its support libraries) with the default platform alignment works, setting SNC_LIB to the path to libgssapi_krb5.dylib.

I applied the top commit from https://github.com/kaduk/krb5/commits/sap and built MIT krb5 locally, as I'm more familiar with that build system than the native OS X Heimdal.  Note that MIT krb5 does not currently understand the default API credentials cache used by the base system Kerberos installation, so the hand-build kinit should be used as well as the GSS-API library.

This is a way to get the SAP client running on a developer's system, but it does not seem like the optimal strategy for deployment on user workstations.  I am still investigating building a shim around the system-provided GSS-API library as a SNC Adapter.

[erik_hendrix · Accepted solution]

Thanks for the explanation. Looks like Apple is going to leave it as is for now based on the information I found here: http://openradar.appspot.com/13218454. Seems like this was a bug where they left something in when moving to 64-bit, and now it is hard for them to remove as it would break a lot of other applications using the library.

I did find out however, that gsstest does not crash when I modify the gssapi_2.h file. Adding:

#if defined(__APPLE__) && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__))

#pragma pack(push,2)

#endif

at the top of the file and then

#if defined(__APPLE__) && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__))

#pragma pack(pop)

#endif

at the end.

[Former Member · Accepted solution]

Thanks for the openradar link.  The core issue here is what's known as an ABI incompatibility -- the GSS-API library exports a function (well, many functions), and the SAP application calls those functions to implement the SNC.  However, in order to call a function, its arguments need to be passed from the calling function to the implementation, and this is a binary interface.  Arguments can be passed in registers or on the stack, and there is an architecture-specific specification for how the different arguments are passed (which ones go on the stack, or which processor registers, etc.).  The ABI incompatibility we see here is particular to a single GSS-API type (and other types which embed it directly): the gss_OID_desc type is specified as a 32-bit length field and then a pointer to the elements of the OID.  For the x86_64 architecture which is used on modern 64-bit macs, the default layout for such a structure is to have the pointer (which is a 64-bit value) be placed at a memory address which is "64-bit aligned", that is, a multiple of 8 bytes.  Because the gss_OID_desc structure contains a 64-bit-aligned value, the convention requires that structure itself to also be 64-bit aligned.  This, in turn, leaves a 32-bit gap between the end of the 32-bit length field and the start of the pointer.

However, the system-provided GSS-API library for OS X does not use the default layout for this structure, because it has the pragma pack() lines that you noticed, which tell the compiler to force 16-bit alignment for everything.  (As the openradar post notes, this originated for compatibility with MIT krb5's GSS-API library, which also has this historical mistake of 16-bit alignment.)  Because 32 is a multiple of 16, the pointer value in the gss_OID_desc structure can now be placed immediately following the 32-bit length field with no gap.

The ABI incompatibility then results from the SAP application expecting the gss_OID_desc structure to have these 32 bits of padding between the length and the pointer, and putting those unused bytes in place when it calls into the system's GSS-API library, but the system GSS-API library expecting no padding.  When a structure created in one place is used in the other and the pointer dereferenced, the pointer is not interpreted as a valid pointer due to the disagreement about the 32 bits of padding, and dereferencing an invalid pointer causes a segmentation fault (and application crash).

Causing the gsstest program to use the same 16-bit alignment that the GSS-API library uses will, of course, make the gsstest program work, but it cannot have any effect on the actual SAP GUI application that we want to use.

It is interesting that though there are many GSS-API types which consist of a length followed by a pointer, only the gss_OID_desc (and related types) is affected here, because the other types use a size_t for the length instead of an explicit 32-bit length field, and on 64-bit macs, size_t is 64 bits, so there is no padding at all, whether the structure is packed using the default system alignment or explicit 16-bit alignment.

[erik_hendrix · Accepted solution]

Hey Rolf,

Would it be possible to see an example of how to invoke gsstest for Kerberos authentication? When I try to run it I provide it with the target_name (-a parameter) of SAPService<SID>@<domain> but it is not working, stating no valid credentials found.

I have been able to get a sncadapt library to work as 64-bit and gsstest so far is producing the exact same results without crashing, but this is without valid credentials.

As a quick test, I start Java GUI 7.3 (64-bit) pointing SNC_LIB to my new library and I got logged on with SNC. So it seems to be working so far but would like to ensure through gsstest that it passes everything as well.

Thanks.

[Former Member · Accepted solution]

I just got gsstest set up for my thin shim -- I copied build.NetBSD to build.Darwin and tweaked a couple of things, and faked up some values for platform.h under defined(__APPLE__).

Are you doing a full GSS implementation for your SNC adapter or just a thin shim? (Will you be able to make it public?)

Anyway, I first tried invoking it as './gsstest -l /path/to/sncgss.dyld -a <actual principal name>', and got a complaint that actual_mechs from gss_acquire_cred() contains 2 gss_OID elements, 1.3.5.1.5.2.7 (first) and 1.2.840.113554.1.2.2 (krb5, second).  My tests aborted early because no security contexts can be established.  gss_acquire_cred Acc() == (GSS_S_NO_CRED), gss_display_status() = "No credentials were supplied, or the credentials were unavailable or inaccessible."  This seems to be because gsstest needs to be the acceptor as well, so that it can control both sides of the security context exchange; you will need to use the principal name for a keytab that is available on the machine in question (and readable by the user running gsstest).  This should not be the actual production SAP principal!

It seems that the acquire_cred shim may need some persuasion.  I know that in recent MIT krb5's GSS libraries, credential resolution is delayed, so acquire_cred() need not actually acquire credentials (inquire_cred() should suffice to force resolution).  It is possible that the native system Heimdal library is doing something similar.  I will hopefully be pushing my work in progress to https://github.com/kaduk/osxsnc soon, I believe it will fall under a BSD license.

[Former Member · Accepted solution]

My code is up, and I included a log of the gsstest output as well, for comparison purposes.

I sent mail to Martin Rex asking whether a shim like this should use the existing krb5 adapter ID or if it requires a new one.

[RMW · Accepted solution]

Hello Benjamin and Erik,

good to read about your great progress in this matter, hats off.

This morning I have asked the very same Martin you already mentioned to look into this thread and give some insights. I hope he is going to follow up sometime next week, when he is back from vacation.

Best regards

Rolf-Martin

[Former Member · Accepted solution]

Thanks for looking into this. Color me as interested.

Cheers,
John

[Former Member · Accepted solution]

I tidied up my code a fair amount, plugging memory leaks and checking for malloc failure.  The only outstanding issue that I know of is that it returns failure if the caller attempts to provide channel bindings to gss_init_sec_context() or gss_accept_sec_context().  This should not be a problem in practice, as the specification for GSS channel bindings is somewhat broken and I don't think they are used by the SAP application.

The osxsnc-1.0-beta1 tag is available from https://github.com/kaduk/osxsnc/releases/tag/osxsnc-1.0-beta1 ; I've asked our team here to do some testing against it, and am happy to look at any issues that may arise from external testing as well.

[erik_hendrix · Accepted solution]

Hey Benjamin,

I was just doing a SHIM. I was using the compiler directives so that the changes would only be in there when compiled for OSX.

I was also starting to use more of a array so that I would store in memory the items and be able to re-use them when the same information was being retrieved to reduce the amount of memory "leaking".

[erik_hendrix · Accepted solution]

Hey Benjamin,

Compiled and been using this version right now. So far no issues.

Does anyone know how one can also check if encryption is being used from the Java GUI to the ABAp client?

[erik_hendrix · Accepted solution]

Just wanted to comment further on this. Downloaded Patch 4 of Java Gui and SSO keeps working. I have had no issues so far with SSO using osxsnc library from Benjamin!!!

After compiling as per instructions, copied the resulting sncgss.dyld to /usr/local/lib and then edited the file: /etc/launchd.conf adding the following line:

setenv SNC_LIB /usr/local/lib/sncgss.dyld

Would be nice if SAP would add this just in their package and then use the Info.plist to point SNC_LIB to the one in their package. Oh well.

[Former Member · Accepted solution]

Hi Benjamin,

I am attempting to get SSO working on OS X using your library, but unfortunately I am running into the error you reference in this reply (gss_init_sec_context()).  I had started my own post, http://scn.sap.com/message/14671586, asking about Kerberos SSO on OS X and Rolf referred me here. I'm curious if you could help me understand how to get passed that error.  The full text of the error is on my post.

[erik_hendrix]

Hey Benjamin,

I'm in the same position. Now with 7.30 rev 3 being 64-bit only Kerberos does not function anymore. So far I do not yet have another solution. Also see the discussion I started for this:

SAP GUI for Java 7.30 Rev 3 - SNC SSO on Mac OSX