Don't forget that OpenSC has a pkcs11-spy library that might be nice to allow for debugging. I'd like to preserve the option for that reason, if nothing else. It would seem to get you into all the interposition issues that libumem has, and I can't tell you how to solve those. |-P
On Sep 11, 2008, at 9:45 AM, Nicolas Williams wrote: > On Thu, Sep 11, 2008 at 06:26:40PM +0200, Mark Phalan wrote: >> ???Was just doing some testing going through the different kinit and >> PKCS11 opts to make sure everything is working ok. One of the options >> which can be given as an argument is a path to a libpkcs11 library to >> use (for e.g. -X PKCS11:module_name=/tmp/libpkcs11.so.1). >> kinit is already linked against /usr/lib/libpkcs11.so.1. Won't bad >> things happen if we dlopen() another libpkcs11.so and start trying to >> call functions from it? Do direct bindings or anything get us >> anywhere >> here? >> I don't have a second libpkcs11.so on my system so and things don't >> seem >> to blow up if a copy of libpkcs11.so is given as an argument to >> kinit. I > > Right, the linker is smart enough not to load the same object twice. > >> guess potentially the libpkcs11.so from opensc could be given as an >> argument.. > > Yeah, things should blow up, though if you use direct bindingins when > building OpenSC you may well avoid any problems. > >> Thoughts? > > Can we exclude that option in Solaris? OTOH, if we package and > deliver > OpenSC then we arguably should not exclude that option, but make it > work instead. > > The two options for making it work: use direct binding when building > OpenSC, or dlopen as RTLD_LOCAL | RTLD_GROUP -- but the latter can be > tricky. > > Nico > -- > _______________________________________________ > kerberos-discuss mailing list > kerberos-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss
