NFSv4 details and documentations

Tue Nov 17 12:53:16 UTC 2015

Slawa Olhovchenkov wrote:
> On Mon, Nov 16, 2015 at 06:00:16PM -0500, Rick Macklem wrote:
> 
> > Slawa Olhovchenkov wrote:
> > > On Mon, Nov 16, 2015 at 10:40:59AM -0500, Rick Macklem wrote:
> > > 
> > > > Slawa Olhovchenkov wrote:
> > > > > On Mon, Nov 16, 2015 at 09:00:09AM -0500, Rick Macklem wrote:
> > > > > 
> > > > > > There is a vfs operation called VFS_SYSCTL(). This isn't
> > > > > > implemented on
> > > > > > the current NFS client. It was implemented on the old one, but only
> > > > > > for
> > > > > > NFS locking events and I didn't understand what needed to be done,
> > > > > > so I
> > > > > > didn't do it.
> > > > > 
> > > > > Rick, I am try to play with NFSv4 and Kerberos and see lack of
> > > > > documentation. For example, nowhere documented that access to NFSv4
> > > > > mount do by NFSv3 rules. I.e. I need have /etc/exports with TWO
> > > > > lines:
> > > > > 
> > > > > V4: /NFS    -sec=krb5i
> > > > > /NFS    -sec=krb5i
> > > > > 
> > > > > W/o second lines I got 10020 error (for NFSv4 mount).
> > > > > 
> > > > Well, "man exports" does try and say this (and I've reworded it several
> > > > times),
> > > > but it is confusing. In simple terms, the "V4:" line does not export
> > > > any
> > > > file system
> > > > and needs to be added to whatever you export via other lines.
> > > 
> > > As I read this: adding '/NFS 127.0.0.1' is enough and secured.
> > This would export the mount to the local machine only (127.0.0.1 is
> > localhost).
> > That is true of NFSv3 as well. If you get the exports working for NFSv3
> > (which
> > can be used with Kerberos, you don't need NFSv4 ot use Kerberos), then you
> > just
> > add the "V4: .." line to define where in the server's file system that the
> > NFSv4
> > root is.
> 
> I am like only one string 'V4: /NFS    -sec=krb5i' and don't need
> NFSv3 at all. But I see this is imposible and documentation don't
> clearly describe this. Im try point this to documentation weaknes:
> NF3v3 permissions checks for NFSv4 mounts.
> 
The only comment I will add is "They have never been NFSv3 permissions".
They started out as NFSv2 permissions, because that was the only version
there was. When NFSv3 was added, nothing changed, because the exports done
for NFSv2 worked for NFSv3 as well. When NFSv4 came along, there was a need
to add information, because NFSv4 combines the exported volumes into one
directory tree and does operations that are not associated with any file,
so the file system based exports don't cover those.

Maybe I should have just done what Solaris did and make the NFSv4 root the
root of the server's file system tree. But, instead, I added a line, so that
the root could be put anywhere. (Linux put the root at the root of one of the
file systems by adding a new option to an existing export line. As such,
all three use the same exports for NFSv4 as NFSv3. Linux added an option to
an existing export line, Solaris just put the root at the root and I added
a new line.)

All the information in the other export lines is still needed, so that
what is exported can be limited to a subtree of the tree and, although
most probably don't do so, how the files are exported can be varied from
file system to file system within the tree (ro vs rw, for example).
Although it does make it more complicated, some may need to do this.

In general, there is always going to be "simple" vs "complicated/comprehensive".
You could ever argue "complicated/comprehensive" is inevitable, because
sooner or later someone needs to export in a way that isn't handled by the
"simple" version and adds that. This repeats until you end up with
"complex/complicated". Since FreeBSD likes backwards compatibility, redoing
/etc/exports in a better was isn't an option (at least not an easy one).
There was an open source altrenative to mountd called nfse which used a
simpler (and better imho) way of doing exports. It never could go in the
tree because it wasn't backwards compatible and the author requested it
no longer be used a while back.
(I am about to review a patch from someone that adds the capability for
 embedded whitespace in host names for /etc/exports, so it will probably
 be even more complicated soon.;-)

All I can suggest is:
1 - Read "man exports" over and over again. After all these years, I still
    read it to remind myself of how it works.
2 - Any improvements w.r.t. documentation will be appreciated by others.
    If you post specific suggested changes to the man pages, someone can
    look at those for a possible commit.
    Otherwise there are doc people that may be able to incorporate what
    you write into the online documentation. (I'm not a doc guy, so I
    don't know the mechanisms, but I suspect posting it to a doc mailing
    list would be a starting point.

rick

> > > 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
> 
> W/o this I can got blocked client site, that can be recovered only by reboot.
> This is lack of unix architecture -- uniterrable open/close/disk IO.
> 
> > (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.)
> 
> This is worked, mount seccess and I can access NFS share from my user
> account.
> May be later I can see some problems?
> 
> > Have fun with it, rick
> > 
> > > > https://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup
> > > 
> > > Yes, I am talk about this.
> > > 
> > > > Anyone willing to improve/update this is more than welcome to do so.
> > > > (I,
> > > > personally,
> > > > haven't set up a Kerberized NFS for a couple of years and I hate
> > > > fiddling
> > > > with it.
> > > > When something isn't working, isolating the problem can be very
> > > > difficult.)
> > > 
> > > Yes, I am already see it.
> > > 
> > > > Good luck with it, rick
> > > > ps: I put it on google as a wiki so anyone could update it, but I don't
> > > > think
> > > >     anyone ever has. As I recall, anyone with a google login can update
> > > >     it.
> > > > 
> > > > > Can you give some examples for kerberoized setup, with support cron
> > > > > jobs?
> > > > > _______________________________________________
> > > > > freebsd-hackers at freebsd.org mailing list
> > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > > > To unsubscribe, send any mail to
> > > > > "freebsd-hackers-unsubscribe at freebsd.org"
> > > > > 
> > > _______________________________________________
> > > freebsd-hackers at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > To unsubscribe, send any mail to
> > > "freebsd-hackers-unsubscribe at freebsd.org"
> > > 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 