[19560] in Kerberos_V5_Development
Re: Internal MIT Kerberos functions used by Samba
daemon@ATHENA.MIT.EDU (Andreas Schneider)
Mon Mar 20 11:35:58 2017
From: Andreas Schneider <asn@samba.org>
To: Greg Hudson <ghudson@mit.edu>
Date: Mon, 20 Mar 2017 16:35:45 +0100
Message-ID: <3002131.WRpP9DMSMh@magrathea.fritz.box>
In-Reply-To: <cd60f660-a1d0-0972-d9a1-52c30412c68b@mit.edu>
MIME-Version: 1.0
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Monday, 20 March 2017 15:54:42 CET Greg Hudson wrote:
> 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.
krb5_error_code decode_krb5_setpw_req(const krb5_data *code,
krb5_data **password_out,
krb5_principal *target_out);
This is the function prototype. It doesn't use any internal structures. So I
do not see how someone would need to use the structure you're talking about.
> 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.
I would say yes, but I haven't looked into RODC (Read Only Domain Controller)
details yet.
> [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.
I would be happy to be able to do all of this in python :) I do not think we
need new functions here.
> 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.
Just having a header which states that it will not have a stable API would be
fine with me.
> I would welcome opinions from other Kerberos developers.
Thanks for considering,
Andreas
--
Andreas Schneider GPG-ID: CC014E3D
Samba Team asn@samba.org
www.samba.org
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
