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

On 10/14/2011 4:18 PM, Nico Williams wrote:
> On Fri, Oct 14, 2011 at 4:12 PM, Harry Coin<[email protected]>  wrote:
>> On 10/14/2011 4:03 PM, Nico Williams wrote:
>>> 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:
>> Clarifying this answer:   discuss your view of the kuserok side of this.
>> Shall it forever
>> be impossible to match principals to local users if those local users have
>> no default or
>> home directory, for example /nonexistent, if the principal name is of the
>> form with a
>> / for examle as specified by GSSAPI->sasl->ldap for service accounts?
> No, not forever, but "forever in the default configuration".  I see no
> reason why a rules- and/or db-based aname2lname system could not be
> devised -- indeed, I intend to implement such a thing at some point,
> for Heimdal (MIT already has one).
>
>>> But again, I don't want to say *never*, just never without additional
>>> configuration.
>> Kindly direct to the appropriate configuration capability.   My reading of
>> the code in kuserok
>>   and aname_to_lname appears to allow no such capability.
> *Today* it doesn't.
>
> Nico
> --
>

Nico, thanks.   Freebsd has integrated heimdal.  MIT's kerberos has 
advanced capabilities in the areas I need to make my current project 
functional right now today,  but I don't see a documented way to specify 
it instead of heimdal.   I'd be grateful to anyone who could point me to 
a single option somewhere that lets me 'recompile the freebsd kernel and 
userland world' with MIT's version.

I urge the heimdal  folk to recognize that there exists a category of 
realm usage which is 'more tightly controlled than usual' shall we say, 
where users with realm-wide single-sign on needs are very few and 
generally administrative in nature.   On the other hand,  I have plently 
of  userX/fqdn principals in the way gssapi likes to see them, but there 
is no meaning for a principal userX@REALM.

So, until you folks clarify the foggy future into code, I'm either going 
to have to write it myself only if that seems less bothersome than 
switching freebsd to MIT's kerberos.