Re: nfs client 'nobody no matter what' clarification was Re: k5userok .c / doc mismatch

On Fri, Oct 14, 2011 at 3:05 PM, Harry Coin <[email protected]> wrote:
> 1: Is it the case that the example principal
> 'alnumstring/[email protected]' will never be associated by
> heimdal (kuserok and friends) to any local account whatsoever, no matter the
> principal type, unless the local user is of the sort that has a default
> directory (e.g. not /nonexistent), and that directory has a .k5login file or
> k5login.d/, and that principal is among those in that(those) file(s)?

First, the principal type means very, very little.  In particular it
means nothing when examining a peer's principal name.

I would not use the categorical language that you use.  I would lika
aname2localname to be sufficiently configurable that
alnumstring/nfsclient.fqdn@CORRECT-REALM could be taken to mean
"alnumstring".

Out of the box, however, Heimdal should not do that ever, not today,
not ever.  Indeed, out of the box Heimdal implements *two* aname2lname
conventions:

 - 1-component principals in any of the local host's default realms
are considered equivalent to usernames where the username is the same
as that one component;

 - 2-component principals where the *second* component is "root" and
where the principals are in any of the local host's default realms,
are considered equivalent to "root" IF they are also listed in the
local root user's ~/.k5login.

> and second,
>
> 2: Asked to deduce a local user from a principal name as in example 1,
> heimdal will fail such requests always even if user alnumstring exists on
> the local system whose hostname is nfsclient and whose domain is domain.com
> and the default realm is DOMAIN.COM?

Yes, see above.

But again, I don't want to say *never*, just never without additional
configuration.

Nico
--