NFSv4 + Kerberos + users

[Kevin Coffman]

On 6/21/07, Zoltan Menyhart <Zoltan.Menyhart at bull.net> wrote:
> I think in this case user_i sees the complete export tree.
>
> Unfortunately, it does not always work.
>
> In two xterms, I have done "kinit" as users root and as linux. As root, I do:
>
> # klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: root at FREC.BULL.FR
>
> Valid starting     Expires            Service principal
> 06/21/07 17:36:04  06/22/07 17:36:02  krbtgt/FREC.BULL.FR at FREC.BULL.FR
> 06/21/07 17:37:29  06/22/07 17:36:02  nfs/lucy2_10g.frec.bull.fr at FREC.BULL.FR
>
> Kerberos 4 ticket cache: /tmp/tkt0
> klist: You have no tickets cached
>
> # mount lucy2_10g:/
> mount.nfs4: Permission denied
>
> Here is what gssd says:
>
> handling krb5 upcall
> getting credentials for client with uid 0 for server lucy2_10g.frec.bull.fr
> CC file 'krb5cc_500' being considered
> '/tmp/krb5cc_500' owned by 500, not 0
> CC file 'krb5cc_machine_FREC.BULL.FR' being considered
> CC file 'krb5cc_machine_FREC.BULL.FR' matches owner check and has mtime of 1181136512
> CC file 'krb5cc_0' being considered
> CC file 'krb5cc_0' matches owner check and has mtime of 1182440249
> CC file 'krb5cc_0' is our current best match with mtime of 1182440249
> using FILE:/tmp/krb5cc_0 as credentials cache for client with uid 0 for server lucy2_10g.frec.bull.fr
> using environment variable to select krb5 ccache FILE:/tmp/krb5cc_0
> creating context using fsuid 0 (save_uid 0)
> creating tcp client for server lucy2_10g.frec.bull.fr
> creating context with server nfs at lucy2_10g.frec.bull.fr
> WARNING: Failed to create krb5 context for user with uid 0 for server lucy2_10g.frec.bull.fr
> WARNING: Failed to create krb5 context for user with uid 0 for server lucy2_10g.frec.bull.fr
> doing error downcall
> destroying client clntae
>
> Why does it even consider using /tmp/krb5cc_500?

The code checks all the files named krb5cc_* in /tmp (or a different
directory if specified).  Prior versions assumed that the credentials
cache file had the uid in the name and further filtered using that,
but not all installations do this.  So it now uses the ownership of
the files to see which ones it might try to use.

As an aside, it is considered bad practice to have a "root" prinicpal
in Kerberos.  root/<instance>@REALM is used, and maybe
<name>/root at REALM, but not root at REALM.

It might be interesting to see what messages svcgssd produced on the
server for this error.

> As the user linux I do a "kdestroy", then mount works.

I'm confused.  What credentials were destroyed?  What credentials did
it use for this mount?

> [ ...]

> Who should own '/tmp/krb5cc_machine_FREC.BULL.FR'?
> Why does it look at '/tmp/krb5cc_0'?

root should own the /tmp/krb5cc_machine_FREC.BULL.FR credentials.
However, they will only be created/refreshed if you are NOT using the
-n flag to gssd.  Now that I think of it, the existence of
/tmp/krb5cc_machine_FREC.BULL.FR and /tmp/krb5cc_0 may confuse the
credentials selection...

> I think "nohide" is not a per user option.
> Can an export line somehow say that "nohide" for "principals x and y"?

Not that I am aware of.