Mac OS X: Calling krb5_init_context and krb5_cc_resolve from a Directory Service Plugin

[Paul W. Nelson]

A quick check in the latest Security Framework for 10.2 does not define
"SessionGetInfo()".  This must be a private API call, since it isn't in any
header file, but is in the framework.

I'll get with Apple on this.  Thanks.

Is there some reason that the credential cache code is not publicly
available for the OS X version (besides it using private API calls)?  This
would be very useful for debugging.

There seems to be a lot of important source code (ccache for example) that
is not available for the OS X version of Kerberos.  This not only makes
debugging more difficult, but prevents others from verifying the correctness
of the implementation.

-- 
Paul W. Nelson
Thursby Software Systems, Inc.

> From: Alexandra Ellwood <lxs at mit.edu>
> Date: Mon, 20 Jan 2003 00:27:33 -0500
> To: "Paul W. Nelson" <nelson at thursby.com>
> Cc: krbdev <krbdev at mit.edu>
> Subject: Re: Mac OS X: Calling krb5_init_context and krb5_cc_resolve from a
> Directory Service Plugin
> 
>> We are developing a Directory Service plug-in that uses kerberos.  We are
>> having major difficulty when calling krb5_init_context and krb5_cc_resolve,
>> because these calls appear to be trying to contact the CCacheServer.app.
>> 
>> The CCacheServer app must be doing something that calls back into Directory
>> Services, and that deadlocks the whole Mac.
>> 
>> Is there some way we can use credential cache names that don't work with the
>> CCacheServer?
>> 
>> Since the credentials cache code on Mac OS X is not publicly available, who
>> should I direct my questions to?
> 
> The API which is deadlocking your program is actually an Apple one:
> SessionGetInfo() from Security.framework.  The Kerberos.framework
> calls this function to determine which CCacheServer to talk to.  You
> never even try to talk to the CCacheServer itself.  SessionGetInfo()
> seems to be dying when your plugin tries to contact the
> SecurityServer, a system daemon, via Mach-IPC.
> 
> You should contact Apple to find out why this function doesn't work
> from a DirectoryServices plugin.  Kerberos needs this function to
> determine which user session your user login is part of.
> 
>> Here is some stuff from a stack trace in DirectoryServer when we lock up:
>> 
>> Program received signal SIGINT, Interrupt.
>> [Switching to process 532 thread 0x1007]
>> 0x90073c48 in mach_msg_trap ()
>> (gdb) thread 4
>> [Switching to thread 4 (process 532 thread 0x2803)]
>> #0  0x90073c48 in mach_msg_trap ()
>> (gdb) where
>> #0  0x90073c48 in mach_msg_trap ()
>> #1  0x90005f90 in mach_msg ()
>> #2  0x92bc3afc in ucsp_client_setup(unsigned, unsigned, long*,
>> unsigned, char const*) ()
>> #3  0x92bb4c3c in Security::SecurityServer::ClientSession::activate() ()
>> #4  0x92bdf3dc in
>> Security::SecurityServer::ClientSession::getSessionInfo(unsigned long&,
>> unsigned long&) ()
>> #5  0x92bdf310 in SessionGetInfo ()
>> #6  0x94341b64 in LoginSessionGetSessionName ()
>> #7  0x94341ad0 in LoginSessionGetSessionUID ()
>> #8  0x94341d00 in mach_client_lookup_server ()
>> #9  0x94341de0 in mach_client_lookup_and_launch_server ()
>> #10 0x9435d240 in CCIMachIPCStub::GetPort() const ()
>> #11 0x94359e50 in CCICCacheDataMachIPCStub::GetCredentialsVersion() ()
>> #12 0x94351b04 in cc_open ()
>> #13 0x943879b0 in krb5_stdcc_resolve ()
>> #14 0x94386d88 in krb5_cc_resolve ()
>> #15 0x0084ca28 in KerbUserInit (user=0xa15c40 "grigsby", domain=0xa159b0
>> "FOO.ORG", passwd=0xa159f0 "zzzzzzz") at
>> <snip>
>> #22 0x00807754 in PlugInShell_ProcessRequest (inData=0xa0d920) at
>> PlugInShell.m:91
>> #23 0x00809548 in _ProcessRequest (thisp=0x0, inData=0xa05360) at
>> ServerModule.c:223
>> #24 0x0000426c in CRequestHandler::HandlePluginCall(sComData**) ()
>> #25 0x00003508 in CRequestHandler::HandleRequest(sComData**) ()
>> #26 0x0001ef50 in CMessaging::SendInlineMessage(unsigned long) ()
>> #27 0x000265d4 in dsDoDirNodeAuth ()
>> #28 0x00009890 in CRequestHandler::DoCheckUserNameAndPassword(char
>> const*, char const*, tDirPatternMatch, unsigned*, char**) ()
>> #29 0x00003f10 in CRequestHandler::HandleServerCall(sComData**) ()
>> #30 0x000034e4 in CRequestHandler::HandleRequest(sComData**) ()
>> #31 0x00003450 in CHandlerThread::HandleMessage() ()
>> #32 0x00003018 in CHandlerThread::ThreadMain() ()
>> #33 0x92b65c68 in DSCThread::Run() ()
>> #34 0x92b65e28 in DSLThread::_RunWrapper(void*) ()
>> #35 0x90020d48 in _pthread_body ()
> 
> 
> --lxs
> -- 
> -----------------------------------------------------------------------------
> Alexandra Ellwood                                               <lxs at mit.edu>
> MIT Information Systems                               http://mit.edu/lxs/www/
> -----------------------------------------------------------------------------
> --
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev