Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Nov 2015 18:08:16 -0500 (EST)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Slawa Olhovchenkov <slw@zxy.spb.ru>
Cc:        hackers@freebsd.org
Subject:   Re: NFSv4 details and documentations
Message-ID:  <183609075.112643195.1448924896262.JavaMail.zimbra@uoguelph.ca>
In-Reply-To: <20151130165940.GB31314@zxy.spb.ru>
References:  <9BC3EFA2-945F-4C86-89F6-778873B58469@cs.huji.ac.il> <3AEC67FD-2E67-4EF9-9D46-818ABF3D8118@cs.huji.ac.il> <661673285.88370232.1447682409478.JavaMail.zimbra@uoguelph.ca> <20151116141433.GA31314@zxy.spb.ru> <1489367909.88538127.1447688459383.JavaMail.zimbra@uoguelph.ca> <20151116155710.GB31314@zxy.spb.ru> <1312967974.89238067.1447714816355.JavaMail.zimbra@uoguelph.ca> <20151130165940.GB31314@zxy.spb.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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").
(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
to "kinit"). The "allgssname" is an odd case for some server no one logs into, which
says "do everything as the host based credential.
--> 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

> 
> 
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?183609075.112643195.1448924896262.JavaMail.zimbra>