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

On 10/12/2011 1:09 PM, Jeffrey Hutzelman wrote:
> On Wed, 2011-10-12 at 19:36 +0200, [email protected] wrote:
>> On Wed, Oct 12, 2011 at 11:51:39AM -0500, Harry Coin wrote:
>>> 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.
>> Ouch.
>>
>>> So, which direction is it going to be, discussed to date we have:
>>>
>>> A1) Some have called this function's existence a bug
>> It looks like that.
>>
>>> C) Let heimdal do A.  But, offer a 'reference design' for B1 that OS
>>> implementers can use for guidance.
>> Ouch. The bug is "the belief that this can be done"
>> ("once and for all services and setups"?).
> Well, no.  The bug is using this fairly legacy code far beyond its
> original intended scope, which was for inferring userids for Kerberos
> authenticated access to user accounts, primarily when using access
> methods that don't provide a way to indicate the desired account name
> separately from the name used for authentication.  For example, login.
>
> Note that this function is not the _authorization_ mechanism for such
> access; that's what krb5_kuserok() is for.  A well-behaved application
> providing Kerberos-authenticated access to user accounts will probably
> need to use both.
>
> Also note that it's not intended for random other services that provide
> something other than "access to user accounts"; implementations of those
> things generally shouldn't be using either function.  This includes an
> NFS server where the users don't really have login accounts.
>

Well there's where one subsystem's 'should' runs into another 
subsystem's 'ought'.   Folk use libraries to deliver whatever value they 
can, the extent to which that fits the developer's intent needs 
reflecting in the code and not the cloud.

Borrowing from current 'lore':   Seems uids>=1000 look to pam/krb5 to 
authenticate and look to nss/ldap to provide the principal to 
whatever-the-local-box-needs name, uid, gid, whatnot mapping.   Look at 
all the 'require minimum uid=1000' lines out there.

The 'uid<1000' world needs to work before and without networking.  
Letting ldap/nss handle the problem like it does for the 'uid>=1000' 
world is not an option.    And locally no os defacto tolerates '/' in 
local account names.   "/home/nslcd\/box"==A fast way to code retirement.

But, some members of the 'uid<1000 club' require kerberized box specific 
principals.

And, some members of the 'uid<1000 club' need to allow rosters of other 
principals to act as .k5login permits for the 'uid>1000' club.

I think that about sums it up.   What's the answer?