NFSv4

[Matt Garman]

On Mon, Sep 30, 2013 at 12:16 PM, Jaap <jwinius at umrk.nl> wrote:

> On Mon, 30 Sep 2013 09:19:07 -0500, Matt Garman wrote:
>
> > For the most part, I do use the default setup.  That is, all my servers
> > with secure NFSv4 mounts have in their /etc/krb5.keytab both
> > "host/hostname at REALM" and "nfs/hostname at REALM" entries.
>
> All I want for now is to know how to have NFSv4 access its encryption key
> if it is stored in a keytab file other than /etc/krb5.keytab.
>


Ahh, I see, that I don't know about.  I just use /etc/krb5.keytab, i.e. the
default.



> Perhaps I'm making a mountain out of a molehill, but I'm under the
> impression that programs that read keytab files tend to stop after
> processing the first entry (with perhaps multiple encryption types). NFSv4
> may be different in this respect, but what would happen if later on the
> nfs key ended up as the first in your /etc/krb5.keytab with the host keys
> after? Then your automatic TGT refreshing mechanism (e.g. k5start) may
> select "nfs/hostname at REALM" instead of "host/hostname at REALM", which could
> be problematic.
>


I just randomly checked a few servers, and my "nfs" key is first, i.e.
before my "host" key... doesn't create any problems that I'm aware of.  I
don't use k5start, but get similar functionality from a simple bash script
named "k5renewd", which was based on the example shown here:


http://www.linuxquestions.org/questions/linux-software-2/automatic-renewal-of-kerberos-tickets-792305/

It's basically just a wrapper around "kinit -R -c <user's credentials cache
file>", and AFAIK, doesn't use the system keytab at all.



> A workaround would be to move the host keys to a different keytab file,
> but I'd rather move the nfs key instead.
>


NFSv4 is currently the only system I'm using that relies on the system
keytab, and it doesn't appear to care about ordering.  So unfortunately, I
can't speak to any other programs.

You could probably also set up a scheme where you maintained several keytab
files, and make "/etc/krb5.keytab" a symlink that pointed to whichever
keytab you needed at different points in time.  For example, you could have
a dedicated keytab file for NFSv4, and instead of letting the system
auto-mount your NFSv4 share at boot, you do it with a start-up script that
points your /etc/krb5.keytab symlink to your NFSv4 keytab, mounts the
share(s), then re-links the symlink to what it was originally.

Kind of convoluted though---just throwing it out as an idea!

Good luck,
Matt




> Cheers,
>
> Jaap
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>