New k5login option proposal for krb5_kuserok

[ghudson@MIT.EDU]

Right now, if a .k5login file can be found for a user, it is treated
as authoritative--that is, any principals not listed there are not
allowed in, even if they map aname-to-lname to the local username.

We've had a request to allow a krb5.conf option to change that
behavior.  If this new option is set, then a principal which
aname-to-lname maps to the local username would be allowed to log in
even if there is a .k5login file which doesn't list that principal.

For this option, I propose the boolean variable
"k5login_authoritative", which would default to true.  If the variable
is set to false, then .k5login files are taken to be evidence of
authorization but not as evidence of lack of authorization.

More generally, we've had a lot of discussion recently about
kuserok-related enhancements, and I've tried to think about how we'll
address all of those requests without creating a spaghetti mess of
options.  In the long term, I'd like to introduce a more formal
concept of kuserok modules, with these simple rules for the
accumulator:

  * A module can return ACCEPT, REJECT, or PASS.
  * Login succeeds if at least one module returns ACCEPT and the rest
    return PASS (i.e. no module returns REJECT).

In phone discussion, Sam proposed a different variable concept which
would modify the accumulator behavior more globally to be more
permissive--that all REJECT answers would be treated as PASS.  I
initially liked that idea, but after further consideration, I'm not
sure how I would name or document it without exposing the concept of
"kuserok module" to a larger class of admins than I would like, and I
became less comfortable with the idea.

In this framework, the current ad hoc krb5_kuserok implementation can
be modeled with the following modules:

  * The k5login module returns PASS if no .k5login file exists, ACCEPT
    if the .k5login file exists and principal is listed, and REJECT if
    the principal if not listed.

  * The aname-to-lname module returns ACCEPT if the principal maps to
    the local username, and PASS otherwise.

If we go in the direction of that framework, I see the following new
features to handle krb5_kuserok-related requests:

  * Make the interface pluggable, so that a database plugin can be
    added without making krb5 reliant on any particular database.
    (The original request was to add database support for
    aname-to-lname.  I'm not sure it would be necessary to separately
    make aname-to-lname pluggable if we had pluggable kuserok.)

  * Add an option to specify where k5login files are found.  This is
    independent of the framework since it can be modeled as a
    configuration option for the k5login module.

  * Since the plugin framework allows built-in modules to be disabled,
    an admin could disable .k5login files by disabling the k5login
    module.

Comments are appreciated.