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

Hello Harry,

On Fri, Oct 21, 2011 at 07:34:58PM -0500, Harry Coin wrote:
> 1. Absent these patches: NFS + kerberos authentication, integrity or
>    encryption security (sec=krb5 krb5i krb5p) only is available for
>    those accounts with kerberos principals having the form xxx@REALM
>    <mailto:xxx@REALM> --with no /.

I understand that you want to make the principal-to-unix-account-name
mapping more flexible for the sake of NFSv4's constrained implementation
(access rights are connected to the local uid on the server so the server
must map a principal name to a local unix account).

Such a mapping arrangement might make sense (on an NFSv4 server) but
at least libnfsidmap-0.24 does not seem to do any mapping via Kerberos
libraries so your patch would be bypassed (which for me seems reasonable,
Kerberos business is between processes, normally of different hosts,
not of Unix local identifiers).

Do your NFS servers behave differently and call aname_to_lname()?

Note that there is a general and straightforward workaround - letting a
daemon use different Kerberos credentials for its own service and for
accessing the NFS service. This should be easy to setup (_is_ easy on
Linux, did not test on other client platforms).

Services other than NFS and login do not need mapping to host-local names
anyway.

> For example if the file
> 
> /etc/k5login.d/ldap
> 
> had the content
> 
> ldap/*[email protected] <mailto:ldap/*[email protected]>
> 
> then any principal using the GSSAPI format ldap/anyboxname.domain.com 
> would be associated with the local user ldap.Calls to kuserok asking 
> whether principal ldap/foo.domain.com matched ldap would return ok.Calls 
> asking aname_to_lname what local user should be associated with 
> ldap/[email protected] 
> would get ldap.

Would you explain for me, when and why your example above or a similar
setup would be needed (you seem to be using this and I want to
understand your case). The above hardly helps for Kerberized NFSv4 (?).
The only other services that I can think about, which concern mapping
to local uids, are login and friends - i.e. initiating processes on a host.
Why would you need to login to a host as "ldap"? How the entity (a human?
another host?) logging in would know the "ldap/the.box" password if it is
in the keytab on the target box and hopefully nowhere else outside the KDC?

If all you need is a login to a host as "root" (which is often
discouraged for good reasons but can be desirable nevertheless), then 
a fully transparent approach would be to set up pam_krb5 so that
on host box1.doma.in it checks passwords of either "account" or
"account"/"box1.doma.in" principals. You have Russ's module which
implements this.

(Also, why do you have to use "root/box1.doma.in" and nothing else?
"root-box1" account in the local passwd, either with uid 0 or with sudo
rights, would be sufficient and a corresponding Kerberos principal would
have the same name.)

In other words, despite having read your notices for the patches
I am still confused and ask for your indulgence and more explanations.
Better look stupid once than remain forever ;)

[The purpose of the keytab name expansion seems otherwise clear (work
around a harmful paranoia check in the library itself). I understand
why you are doing this, even if I'd prefer a different approach.]

Regards,
Rune