NFSv4 and root access

[Matt Garman]

On Fri, May 30, 2014 at 9:19 AM, Jaap <jwinius at umrk.nl> wrote:
> Recently I got NFSv4 to work together with Kerberos (gss/krb5i or gss/
> krb5p) on Debian wheezy, but there's a problem. It has to do with exports
> with "no_root_squash" option; when attempting to allow root on the
> clients to write to them, this always results in a "Permission denied"
> error.
>
> Is there a solution for this, or a workaround?
>
> I'm using rpc.svcgssd and have tried adding the following to idmapd.conf:
>
>   [Static]
>   root/<fqdn>@<realm> = root
>
> Unfortunately, I still got the same result.

I've faced similar issues, although I don't have a compelling need for
root to see user's NFSv4 sec=krb5p home directories, so I've just
lived with it.

However, I've faced a similar situation where some users need to
access krb5p nfsv4 mounts from cron.  What I did here was to create a
dedicated Kerberos principal that's the same as the user, but with
"/cron" appended.  So, for example, say the user's principal (that he
logs in with) is "matt", I'd also create a "matt/cron" principal as
well.  Note the /cron user is created with a random key ("addprinc
-randkey cron/user").

Then under the [Static] section of idmapd.conf (on the nfsv4 server), I have:
matt/cron at REALM = matt

*** Note that you also need "static" listed as one of your GSS-Methods
under the [Translation] section of idmapd.conf, i.e.:

[Translation]
GSS-Methods = nsswitch,static

That one confused me for a while when I was setting this up!

Now, I exported the user's key to a file ("ktadd -k cron_user.keytab
user/cron") and put that file in a public location (e.g. a non-secure
nfs share), but make it mode 600 and owned by the user (i.e. rely on
Unix permissions to protect it from others).

Then, in the user's cron job, then have to first run "kinit -k -t
<keytab_file> user/cron".  And ideally they run kdestroy when their
job finishes.  I wrote a nice little wrapper script to make this easy
for people.

To me, the weakness is having that keytab file out in the open, but I
can't think of a better way to do it.

In theory, you should be able to do something similar for root... I
haven't tried this, but the nfs client machine's /etc/krb5.keytab file
should work for this.

*** Another thing to note, that might get you thinking your config
changes aren't working as expected: there seems to be a per-user
time-based credentials cache, and from experience, I believe it's on
the order of 15 or 20 minutes.  I used to always get grief from my
users, as I'd add them to a new Unix group, have them logout and log
back in, and they'd still not have their new group permission "in
effect"... and then after 15--20 minutes, it works as expected.

I don't know of anyway to force flushing of the cache without
rebooting the machine.

I don't know if that's an exact answer, but hopefully something in
there is useful for you.