[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] statically linking with mechglue-branch
- To: Michael B Allen <mba2000@ioplex.com>
- Subject: Re: [patch] statically linking with mechglue-branch
- From: Gabor Gombas <gombasg@sztaki.hu>
- Date: Tue, 2 May 2006 10:41:30 +0200
- Cc: heimdal-discuss@sics.se
- In-Reply-To: <20060428131137.374fb54c.mba2000@ioplex.com>
- Mail-Followup-To: Michael B Allen <mba2000@ioplex.com>,heimdal-discuss@sics.se
- References: <20060427173340.4076e952.mba2000@ioplex.com> <20060428085205.GC4079@boogie.lpds.sztaki.hu> <20060428131137.374fb54c.mba2000@ioplex.com>
- Sender: owner-heimdal-discuss@sics.se
On Fri, Apr 28, 2006 at 01:11:37PM -0400, Michael B Allen wrote:
> You're right, it's not. But these mech libraries are supposed
> to be agnostic about what gss implementation they use and
> GSS_C_PEER_HAS_UPDATED_SPNEGO is specific to Heimdal's libgssapi. So
> technically a mech shouldn't reference an implementation specific
> symbol. But since it's just an OID definition I think the solution would
> be to simply define a static version of the same OID in the one source
> file that uses it (inquire_context_by_oid.c). Easy.
The problem is, the mech will not just magically know who dlopen()ed it.
The classical solution is to pass a method table to the dlopen()ed
module upon initialization that contains all the symbols it needs so the
plugin does not need any symbol lookups (at least not for mechglue
symbols). This solution is portable and reliable.
If you do not pass such a method table, then the next best thing is to
just link against the mechglue library. This is still portable and
reliable but does not allow for replacing the mechglue lib (at least not
easily).
After that come the not-so-reliable and not-so-portable options. The
first problem that whoever loaded the mechglue library for the first
time, may have dlopen()ed it with RTLD_LOCAL, which means the symbols
from the mechglue library are not visible to the plugins. The solution
in this case is to modify libgssapi.so to dlopen() itself with
RTLD_GLOBAL before loading the mech plugins. This trick works on the
platforms I have tried, but in theory it may cause problems if the
entity loading libgssapi.so had some _real_ reason to use RTLD_LOCAL
instead of RTLD_GLOBAL, and may become confused if the global symbol
space changes. This is unlikely though.
What is much more likely is when you _do_ have two different mechglue
implementations, and they happen to be loaded simultaneously (quite
possible in GUI applications that tend to link to literally hundreds of
shared libraries). In this case there will be multiple definitions of
the same mechglue symbols and it will be completely random (or at least
platform-dependent) which implementation will the plugin pick.
> $ objdump -t /usr/heimdal/lib/libkrb5.so | grep krb5_rd_cred2
> 0002df14 g F .text 00000082 krb5_rd_cred2
objdump -t examines the static symbol table. For dynamic linking you
need the dynamic table (-T).
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------