NFSv4 details and documentations

[Slawa Olhovchenkov]

On Mon, Nov 30, 2015 at 06:08:16PM -0500, Rick Macklem wrote:

> Slawa Olhovchenkov wrote:
> > On Mon, Nov 16, 2015 at 06:00:16PM -0500, Rick Macklem wrote:
> > 
> > > > But this is wrong: not only exported, access control too.
> > > > May be for NFS guru this is trivia, but for ordinary users this is
> > > > confused.
> > > > 
> > > > > > What current status Kerberos support in NFS client/server? I found
> > > > > > many posts and wiki pages about lack some functionality, but also see
> > > > > > many works from you.
> > > > > > 
> > > > > The main limitation (which comes from the fact that the RPCSEC_GSS
> > > > > implementation
> > > > > is version 1) is that it expects to use DES, which requires "weak
> > > > > authentication"
> > > > > to be enabled. Although parts about adding patches for initiator
> > > > > credentials no longer
> > > > > applies, this is still fairly useful.
> > > > 
> > > > Hmm, I am have setup Kerberized NFS w/o "weak authentication" to be
> > > > enabled, with mounted as
> > > > 'nfsv4,intr,soft,sec=krb5i,allgssname,gssname=root'. What is requred
> > > > DES in RPCSEC_GSS? (for me as user, how I can see what broken? some
> > > > commands don't working or something else?)
> > > > 
> > > Well, if the mount is working, you aren't broken. I do recommend against
> > > using "soft" or "intr" on NFSv4 mounts, because the locking stuff
> > > (which includes file opens) breaks if an RPC gets interrupted.
> > > That is on one of the man pages, maybe "man nfsv4".
> > > 
> > > Usually you can't create the keytab entries unless you enable weak
> > > authentication,
> > > but if you've gotten it working, be happy;-)
> > > (DES is used for krb5p and none of the Kerberized NFS stuff works for
> > >  excryption types with larger keys than 8 bytes, from what I know. I
> > >  always used des-cbc-crc, because that is what all clients/servers are
> > >  supposed to support. Once you move away from that, you are experimenting
> > >  and it works or not.)
> > 
> > mount is working, but all access (from any accounts) go from mounting
> > credentials (if I mount allgssname,gssname=host -- as root and mapped
> > to nobody, if I mount as user -- all access as user, root also as
> > user). What I am missing or missunderstund?
> > 
> Yes, that sounds correct. The mapping of "root" is somewhat more unusual.
> It depends on what you called the host-based principal in your /etc/krb5.keytab.
> If you use "root@<client-host>.<domain>", then system operations are done as
> "root", assuming you have "root" in your KDC (most don't). Otherwise, "root"
> ends up as "nobody".
> 
> The most common variant of the mount (which requires a host-based credential in
> /etc/krb5.keytab on the client) is done with gssname=host (but not "allgssname").

Yes, my mount use "allgssname", I am think "gssname=host" require
"allgssname" too.

> (Note that "host" here implies that the principal for the host-based credential is
>  "host@<client-host>.<domain>". --> What is after the "=" above is what is before the
>  "@" in the host based principal name.)
> Then system operations are done as nobody, but users are done as that user (they need

This is strange. I am mount (by automount) as:

/NFS    -nfsv4,intr,soft,sec=krb5i,gssname=host storage01:/

in rc.conf:
gssd_enable="YES"
gssd_flags="-h"

In this case, I am can't login to user with $HOME on this NFS --
root (sshd run as root and PAM accounting run as root -- check
.k5login and etc) totaly don't have access (10016).

I am avoid this by "kinit -k host/`hostname`" in crontab and startup
script, but may be gssd is best for this functionality?

> to "kinit"). The "allgssname" is an odd case for some server no one logs into, which
> says "do everything as the host based credential.

I am confused by "allgssname", I am don't think that is like -mapall=
in exports, I am think this is only for mount and for case absent user principal.

> --> If you need "root" access, you must put a "root" principal name in your KDC and
>     then create the host-based credential for /etc/krb5.keytab using the principal
>     name "root@<client-host>.<domain>".
> 
> Yes, it is confusing, but that's Kerberos for you;-) rick