issue with krb5_prompter_posix() design

[Russ Allbery]

Nicolas Williams <Nicolas.Williams at oracle.com> writes:
> On Thu, Apr 15, 2010 at 02:31:02PM -0700, Russ Allbery wrote:

>> This allocator/deallocator matching problem is often thought of as only
>> a Windows issue, and hence not relevant to PAM, but I'm seeing more and
>> more application software use its own allocators for one reason or
>> another.  (OpenLDAP, for example.)  In combination with dynamically
>> loaded libraries and modules and various types of symbol binding, this
>> can cause weird issues if allocations and deallocations cross library
>> boundaries.

> Note though: while I think good hygiene alone demands that allocation/
> deallocation not cross API boundaries, it is a very, very, very, very,
> very, very, very, VERY bad idea to make libraries use their own
> allocators by default, and worse, much, much, much worse to _require_
> that their callers tell them what allocators to use.  The same thing
> applies to synchronization primitives.

Yes, agreed.  To be clear, custom allocators come up with OpenLDAP in the
context of the slapd server, not the library.

> All library API designers should expect multiple distinct callers in one
> process and aim to have zero global variables/state.  Any state that one
> is tempted to think of as global should be encapsulated in a handle
> (such as krb5_context).  Look at any major library that you can think
> of, say, NSS, PKCS#11, OpenSSL, libevent -- all of them have got this
> wrong, and some of them have thankfully evolved to address this (e.g.,
> libevent).

Yes.  The library world thankfully looks a lot more like object-oriented C
than it used to, but there's still work to do there.  (The most relevant
example I can think of in the Kerberos library space is the difficulty in
specifying the Kerberos configuration, default ticket cache, and keytab
file through various API boundaries, particularly GSS-API; there are APIs
that mostly do the right thing for some of those, but they're not widely
used.  And memory ticket caches are exactly the sort of global state
that's hard to deal with and breaks in various shared library combination
scenarios.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>