krb5.conf and 32 vs 64-bit plugins

[Tomas Kuthan]

On 08/17/15 02:35 PM, Roland Mainz wrote:
> On 14 August 2015 at 15:48, Tomas Kuthan <tomas.kuthan at oracle.com> wrote:
>> On 08/14/15 03:02 PM, Roland Mainz wrote:
>>>
>>> On 14 August 2015 at 14:43, Tomas Kuthan <tomas.kuthan at oracle.com> 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/pkinit.so
>>>>
>>>> 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/libc.so
> ...) ... but I am not sure whether this is a PSARC "contracted"
> interface or a public one...
>
> ----
>
> Bye,
> Roland
>

Hi Roland,

on Solaris, instruction set specific shared objects have been deprecated 
in favor of capabilities, see S11.2 Linkers and Libraries guide:

     Note - This token is obsolete, and might be removed in a future
     release of Oracle Solaris. See “Capability Specific Shared Objects”
     on page 253 for the recommended technique for handling instruction
     set extensions.

All the evidence I was able to gather suggests, that on Solaris alone 
32/64-bit distinction in paths is sufficient. But for multi-platform it 
is a different story I guess.

Thanks,
Tomas