krb5.conf and 32 vs 64-bit plugins

Roland Mainz rmainz at
Mon Aug 17 08:35:54 EDT 2015

On 14 August 2015 at 15:48, Tomas Kuthan <tomas.kuthan at> wrote:
> On 08/14/15 03:02 PM, Roland Mainz wrote:
>> On 14 August 2015 at 14:43, Tomas Kuthan <tomas.kuthan at> wrote:
>>> Hi team,
>>> in Solaris we deliver 32-bit Kerberos libraries under /usr/lib and 64-bit
>>> libraries under /usr/lib/64. The same holds for plugins, which reside in
>>> /usr/lib/krb5/plugins and /usr/lib/64/krb5/plugins respectively.
>>> Specifying a plugin in krb5.conf works fine when relative paths and
>>> default
>>> plugin_base_dir are used. The plugin_base_dir defaults  to
>>> /usr/lib/krb5/plugins on 32-bit and to /usr/lib/64/krb5/plugins on 64-bit
>>> and plugins with the correct ISA are used.
>>> Things start falling apart, when user would like to either specify full
>>> path
>>> to the plugin or set a non-default plugin_base_dir in their krb5.conf. In
>>> that case only one of the paths can be specified in krb5.conf, meaning
>>> plugins would fail dlopen-ing on the other architecture.
>> Note that KRB5_CONF and KRB5_KDC_PROFILE can be a (POSIX-shell style)
>> $PATH, so in *theory* you could provide ISA-specifc configs that
>> way... :-)
> Indeed, in theory.

Yes, not nice, but something which can be used without having to go
through PSARC ...

>>> We would like to solve that by supporting $ISA place holder in the path,
>>> that would translate to '/64/' on 64-bit and to '/' on 32-bit. Hence the
>>> following (artificial) example would work fine for both:
>>>      module = pkinit:/lib/$ISA/site/preauth/
>>> Would MIT be willing to accept a patch implementing something along these
>>> lines?
>>> If yes, I would prepare a platform-independent fix.
>>> FYI, attached is a quick unix-only patch.
>> IMHO it would be better to look at the options provided by the POSIX
>> standard (e.g. see $ ksh -c 'builtin uname ; uname --help #) for a
>> list of keys.
>> Otherwise it will be tricky from the scripting (or any POSIX API-based
>> application) to figure out the correct values (remember, there isn't
>> only 32bit and 64bit, for example on Solaris/SPARC you have more
>> architectural choices (see $ isalist # output and the isaexec stuff))
>> - unless you want to either hardcode the values for every possible
>> combination OR limit the choices to 32bit vs. 64bit (not wise - see
>> SPARC example).
> I might be misunderstanding you here, but limiting the choices to 32bit vs.
> 64bit is exactly what I want.

Erm... this will ONLY work for x86/AMD64 but NOT for SPARC because
SPARC has more than two ISAs/architectures (and technically if you add
SSE/SSE/etc. to the mix then it will be a problem for x86/AMD64, too)
... please take a look at the output of the isalist(1m) utility on
Solaris and then you'll see what I mean.

If you take a look at bugster (yes yes, I've been a SUN'y too long
ago) or whatever Oracle forced you to use as bug database these days
there is a common pattern: 1. Engineers add 32/64bit directories 2.
Few months later said engineers are slapped over by another devel
group, engineering management or PSARC because "...only 32bit/64bit
has been accounted for, not the while list of ISAs on SPARC...".
My suggestion is NOT to repeat that pattern and just make room for
more than two ISAs ([1]).

[1]=And "yes", I know that the runtime linker is now able to make ISA
choices (like done for libc, replacing the Solaris 10/OpenSolaris
solution of using lofs to mount the right ISA libc over /lib/
...) ... but I am not sure whether this is a PSARC "contracted"
interface or a public one...



  __ .  . __
 (o.\ \/ /.o) rmainz at
  \__\/\/__/  IPA/Identity Management/Kerberos 5
  /O /==\ O\
 (;O/ \/ \O;)

More information about the krbdev mailing list