On Thu, Sep 11, 2008 at 11:45:35AM -0500, 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.
Perhaps I'm off base here but wouldn't it be better to add whatever pkcs11/smart card functionality OpenSC has to the native Solaris pkcs11 and just have kinit continue to use that. I'm not wild about adding more options to krb utils if they aren't absolutely necessary. If we must support "-X PKCS11:module_name=/tmp/libpkcs11.so.1" then this should be error tested carefully to make sure the user can't cause a core dump and should get meaningful error messages. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/
