optionally require explicit authorization for krb5_kuserok API / k5login file

[Tom Jones]

This is a preliminary mail to open a discussion about optionally
requiring explicit k5login authorization for the purposes of
krb5_kuserok(3) and any other relevant APIs.

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.  Instead, absence of the file
results in the "krb5_aname_to_localname" mechanism kicking in.
Basically, if the local user name matches the principal name up to the
@, and it's in our home realm, access is granted in the absence of the
k5login file.

I hope it's obvious why such a setting may be wanted, but I'm happy to
provide general justification and example scenarios if asked.

Copying the approach taken by "k5login_authoritative", a way to design
the interface of this feature would be to define a new libdefaults
setting called, say, "k5login_required" with a default value false,
ensuring backwards compatibility.  krb5.conf(5) would need updating.
Looking at the text for krb5_kuserok in doc/api/libos.tex, this brief
specification would still be correct after introduction of the feature
and so would not need changing.

Moving on to implementation.  There seem to be two possible places where
the new logic could be put in.  One is in kuserok.c:krb5_kuserok to set
a condition for calling an2ln_ok.  The other is in an2ln_ok itself.  The
choice appears to largely depend on the detail of the intended semantics
of an2ln_ok (not a public API as far as I can tell).

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?  I can discuss an equivalent
change with them separately, of course, but was wondering whether you
have an ongoing coordination activity.

Any thoughts on any of this before I dive in to doing it?

  regards, Tom Jones.

-- 
Tom Jones, BCCX Ltd