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

Can we focus a bit on 'bridging the gap' to add a bit more to the 
'broken here and now', as the shape of the future has been given some air?

Here and now, objectively,  heimdal has a function, documented and not 
deprecated, that converts principal names to local names, that a 'grep 
-r' at the top of your favorite OS source tree shows is used by nfs at 
the least.

That heimdal function imposes the principal to local requirement that:

1.  no principal name having two or more / can have any local name--- 
full stop--- whether or not authentication routines can provide a 
uid:gid for it.

2.  a principal name of two parts when the second part is not 'root' can 
have no local name-- whether existing locally or not, as per 1.

3.  a principal name of two parts when the second part is root, if the 
principal is in the root's .k5login, will be given local 'root'.

4. a principal name of one part, whether recognized by the local system 
or not, whether root or not, is returned whole minus the realm as the 
local name.

So, which direction is it going to be, discussed to date we have:

A1) Some have called this function's existence a bug, leftover dna 
(nevermind present ubiquitous use) and want it removed.  Let those who 
want to link with the next version of heimdal do what they deem wise.  
Why is heimdal in the business of dealing with what passes for a local 
name anyhow?  Straying from pure-authentication too much.  Local user 
existence lookups are not portable, anyway.

B1) Others think to 'double down' and 'go large'.  Add a 
principal-to-local user configurable name re-write engine, look in the 
.k5login or similar for the resulting user and if that user exists and 
the principal is allowed succeed otherwise fail.

B2) B1 except having arrived at a local user name, no validation it 
exists or that access is permitted.

B3) B2 except if the local user name is root, then B1.  (Current behaviour).

C) Let heimdal do A.  But, offer a 'reference design' for B1 that OS 
implementers can use for guidance.

Meanwhile,  this/that@realm owed by your:choice on linux nfs clients 
gets mapped to nobody:root on freebsd nfs servers, v3 and v4.  No errors 
reported, no debug messages to be found.  Thought it was about -maproot 
since my first encounter was root/<fqdn>, but no it's anything of the 
form this/that@realm.   Rune suggests putting this/that in the freebsd 
passwd file.

Basically, the tension comes as we'd like to avoid having ldap or 
similar entries for every network using process on every box with uid < 
1000 as the uid/gid they are assigned varies across bsd, nix , is etc.  
We want local process/daemon uid:gids to stay entirely local.