[15672] in Kerberos_V5_Development
Re: issue with krb5_prompter_posix() design
daemon@ATHENA.MIT.EDU (Russ Allbery)
Thu Apr 15 17:31:06 2010
From: Russ Allbery <rra@stanford.edu>
To: MIT Kerberos Dev List <krbdev@mit.edu>
In-Reply-To: <20100415210317.GX10389@Sun.COM> (Nicolas Williams's message of
"Thu, 15 Apr 2010 16:03:17 -0500")
Date: Thu, 15 Apr 2010 14:31:02 -0700
Message-ID: <878w8oe73d.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Nicolas Williams <Nicolas.Williams@oracle.com> writes:
> Yeah, yeah, whoever said that PAM is intended to be portable? Ah, but
> it has turned out to be used elsewhere, outside Solaris. But even
> ignoring the fact that Solaris makes it easier/more likely for apps to
> work with a single allocator process-wide (and the fact that I think
> that this is a Good Thing), I believe it's best to isolate allocator use
> by library. Meaning: that an API should provide its own deallocators
> for all objects that it allocates, and should not deallocate objects it
> did not allocate except through their corresponding deallocators (as
> opposed to free()). This principle is difficult to apply to prompters,
> I agree, but hardly impossible.
I wholeheartedly agree.
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.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
