Suggestion re: kuser_ok / aname_to_localname

Should a general purpose authentication library be in the business of 
forcing whether a map between a principal name and a local user/service 
name is 1-1, many-1, 1-many or many-many?

Plainly regular expressions have a role if avoiding updating lists of 
principals in 'k5login-ish' files across many systems every time a new 
principal is added.  Without regular expressions having a role one must 
contemplate vast acls or maintaining something feeling like group 
membership files --which is nothing more than pushing the .k5login admin 
problem into the security library next door.

We have occasions when the krb5 library is asked whether a known local 
name allows a specific principal name.  (kuser_ok)

We have occasions when the krb5 library is asked to deduce a local name 
from a principal name. (aname_to_localname)

Let's pass over the rather eclectic detail characterizing the present 
nature of that activity (e.g forcing accounts that otherwise have no 
need to have 'home directories' and .k5logins if they want to match 
anything with a /, whether */root is or isn't special, what happens if 
there is no .k5login, the prospect of forcing admins to create scripts 
and daemons rummaging around tuning selected k5logins across the realm 
every time a principal matching a certain pattern is added).

Consider these three changes:

1) add to the list of literal principals, regular expressions in the 
.k5login file, of the sort seen in MIT's auth_to_local before the s///.

2) add to the realm a default regular kuser_ok expression for users 
having no proper .k5login, which itself defaults to capturing current  
kuser_ok behavior, such as it is.

3) add to the realm zero or more princ_to_local=(patternmatch 
regex)s/x/y/ (result is local username tried against krb5_kuserok).
First one to hit, wins the 'find first' routine, 'find next' continues. 
Default if no princ_to_local captures current aname_to_localname behaviour.

In that way, one goes MIT's kerberos one better, no requirements about 
whether mappings among principals and users be 1-1, 1-many, many-1 or 
many-many.  A principal might be allowed by a local user which user is 
not by default selected based on the principal name alone.    But, the 
user has control as creating a .k5login can now allow classes of 
principals without having to list them all.  No presuppositions about 
what makes for a local user name.  And, no forcing acl cousins to 
maintain vastish databases of which principals are in what group of like 
principals able to access common files as owners and not group members, 
such as 'ldap' and off-box systems in chrooted jails with uid=0, etc.

I suppose one might consider adding options blocking 'one line .k5logins 
that create 'Everyone' accounts' for ranges of uids.

My $0.02 that makes managing gssapi/sasl/nfs 3 or 4 +kerberos alot 
easier, keeps current behavior for those that need it, and is reasonably 
future proof.

Harry Coin