krb5.conf and 32 vs 64-bit plugins

[Roland Mainz]

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

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