[19559] in Kerberos_V5_Development
Re: Internal MIT Kerberos functions used by Samba
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Mar 20 10:54:55 2017
To: Andreas Schneider <asn@samba.org>, MIT Kerberos Dev List <krbdev@mit.edu>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <cd60f660-a1d0-0972-d9a1-52c30412c68b@mit.edu>
Date: Mon, 20 Mar 2017 10:54:42 -0400
MIME-Version: 1.0
In-Reply-To: <2937171.09XylbPPP0@magrathea.fritz.box>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Thanks again for writing this up.
On 03/20/2017 05:45 AM, Andreas Schneider wrote:
> The MIT Kerberos library has several symbols which are public but do not offer
> a prototype in a header file.
Just to be clear, we don't consider functions exported by libkrb5 to be
part of the public API unless they have a prototype. In most cases
those symbols are exported for ease of testing or by use in other parts
of the tree.
[for the Samba kpasswd server]
> decode_krb5_setpw_req
The krb5_setpw_req structure is also not public.
If the only reason Samba needs its own kpasswd server is access control,
I would hope that is a temporary need, although we've been very slow to
create a pluggable access control interface for kadmind's password server.
[for the Samba test suite]
> decode_krb5_error
> decode_krb5_as_req
> decode_krb5_as_rep
> decode_krb5_padata_sequence
> krb5_free_kdc_req
> krb5_free_kdc_rep
> krb5_free_pa_data
We have krb5_rd_error() which wraps decode_krb5_error(). This and
krb5_mk_error() exist for applications which use KRB_ERROR messages in
their protocols, such as kprop.
One option would be to add similar krb5_rd_kdc_req(), krb5_rd_kdc_rep(),
and krb5_rd_padata() wrappers, or some variation along those lines. The
argument against doing this is that libkrb5 isn't designed to be a
nuts-and-bolts encoding library for test suites. I've done some
preliminary work on a Python library for this purpose, but I stalled out
after implementing the crypto layer.
A more conservative option, in the sense of not making a long-term API
commitment, would be to create a new public header marked as unstable
across releases, containing prototypes for a set of encoding and
decoding functions, and perhaps some formerly private structures such as
krb5_setpw_req.
I would welcome opinions from other Kerberos developers.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
