optionally require explicit authorization for krb5_kuserok API / k5login file

[Greg Hudson]

On 06/12/2013 03:37 PM, Tom Jones wrote:
> Currently, the "k5login_authoritative" libdefaults setting can be used
> to control whether a k5login file should be considered exhaustive, *if
> such a file exists*.  However, there does not appear to be a way to
> require that a principal is explicitly authorized via a k5login file,
> refusing access if the file doesn't exist.

This will be directly possible in 1.12 with:

    [plugins]
        localauth = {
            disable = an2ln
        }

See also:


http://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html#localauth-interface

http://k5wiki.kerberos.org/wiki/Projects/Local_authentication_pluggable_interface

Having to do this via plugin configuration isn't really optimal, but
this is also (so far) an uncommon use case.  If it were more common,
we'd probably make the an2ln module read a profile option in
[libdefaults] to decide whether to disable itself.

In current and prior versions of krb5, it's possible to effectively
disable the aname_to_localname framework with something like:

    [realms]
        (name of default realm) = {
            auth_to_local = RULE:[0:x](y)
        }

but that's not very elegant, and it disables aname-to-lname translation
for all purposes rather than just krb5_kuserok.

> Looking at the text for krb5_kuserok in doc/api/libos.tex

We should probably get rid of that.  Currently, API documentation is
maintained via doxygen comments in krb5.hin and then formatted using
Sphinx; see:


http://web.mit.edu/kerberos/krb5-latest/doc/appdev/refs/api/krb5_kuserok.html

> Finally a question about how this stuff is specified.  Is there a
> process to coordinate the interface change parts of this (ie the extra
> krb5.conf setting) with either a separate interface specification group
> which also has heimdal etc folks on it, or directly by liasing with
> heimdal as the other main implementation?

We pay some attention to what each other do, but we don't formally
coordinate, and the implementations aren't always interface-compatible.
 I wouldn't expect Heimdal to duplicate our [plugins] configuration section.