aname_to_locaname vs gssapi svc/host.domain.org@REALM

So, kindly look at 
https://github.com/heimdal/heimdal/blob/master/lib/krb5/aname_to_localname.c. 


There is a conflict both with 'kerberos is principal name agnostic' and 
gssapi's requirement of host/fqdn format principal names, and through 
that nfs3 and nfs4 servers forcing local roots with gssapi authenticated 
names to be 'nobody' no matter -maproot=root on the server when nfs clients.

Diskless clients that are forcing =sec:krbX need their root and other 
principals to not be 'nobody' to the server file system.  Hence the nice 
-maproot:=root feature of nfs.   Except names in the format required by 
gssapi of x/box@realm are forced to 'nobody' by nfs servers when nfs 
clients before the -maproot bit has a chance to work on it.

In the above krb5 library routine, there we see that if the principal 
name has no '\' its length is 1 and that  minus the realm is passed on 
to be the local name without checking krb5_kuserok (which is done below) 
, no matter root, or not.  So far, so good.  Straight parsing.  Channel 
Rune and leave whether authentication needs to happen to functions with 
that in the title.

Next we see if the principal name length is 2  (x/y@realm), only if the 
y is 'root' does any further processing occur (making reference to the 
local root's .k5login file via krb5_kuserok).  So there is not just a 
parsing going on there, but an authentication/authorization check as 
well.   Note oddly root@realm is not checked by krb5_kuserok-- worse if 
multiple realms match (uh-oh...).

But, while rejecting all Russ' gssapi rfc format principals  host/<fqdn> 
nfs/<fqdn>  root/<fqdn>  daemon/<fqdn> and so forth: 
'Whatnot/root@realm' gets checked against the local root's .k5login. 
(Look in vain for that bit of 'lore/root' magic in the heimdal docs.. 
or even find the function itself on the heimdal doc pages).

aname_to_localname goes on: we see that if the second part of the name 
is not root, or the name has more than two parts,  the name is rejected 
entirely as not possibly  having any local name at all.  NFS server 
upshot -- uid==Nobody.

What then are we to make of the gssapi rfc  which specifies two part 
names where the second is never root, but is instead a box fqdn, such as 
  '<pick one, host, nfs, root, nslcd..>@box.domain.org'?

Certainly XXX/the.box.I'm.running.on.org@Any-matching-REALM meets the 
definition of 'local name' and ought to return the 'XXX' part.  Also 
should any of my local user/service accounts have .k5logins that include 
XXX/otherbox@allowed-REALM the XXX should be approved as a local name. 
(now, where would one look for a service's .k5login that doesn't have a 
home directory in /etc/passwd and what to do if there isn't one?  Is 
root/<fqdn> a service client, host or person?  Is host/<fqdn> a client 
or a service?)

perhaps instead of just failing without trying multipart names, the code 
should be:

   if (aname->name.name_string.len ==0) return KRB5_NO_LOCALNAME;
   res = aname->name.name_string.val[0];
   if (aname->name.name_string.len>1) {
	krb5_principal princ;
	krb5_boolean userok;

	ret = krb5_copy_principal(context, aname,&princ);
	if (ret)
	    return ret;
	
	userok = krb5_kuserok(context, princ, res);
	krb5_free_principal(context, princ);
	if (!userok)
	    return KRB5_NO_LOCALNAME;
   }
... current:
  len = strlen (res);
     if (len>= lnsize)
	return ERANGE;
     strlcpy (lname, res, lnsize);

     return 0;



Or, skip the whole 'check if length>1' thing and accept only those for 
which krb5_kuserok comes back good (my choice). This authentication 
check for some principal name formats but not others is like being half 
pregnant.

Or, abandon all the authentication stuff, and after validating the realm 
match simply return whatever the first part of the principal name is.

And/Or -- add a local database lookup of userid as a post-processing 
validator and return ok only if the proposed local name exists locally.

In any event, it sort of breaks NFS + kerberos for a whole class of apps 
here.

Hopefully my newness is showing, and I've missed something both obvious 
and important that makes this whole problem go away.   Kindly guide!

Thanks

Harry Coin