Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Nov 2015 20:09:17 +0300
From:      Slawa Olhovchenkov <slw@zxy.spb.ru>
To:        Rick Macklem <rmacklem@uoguelph.ca>
Cc:        hackers@freebsd.org
Subject:   Re: NFSv4 details and documentations
Message-ID:  <20151117170917.GE31314@zxy.spb.ru>
In-Reply-To: <1391183052.90077969.1447764792244.JavaMail.zimbra@uoguelph.ca>
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> <20151117051820.GD31314@zxy.spb.ru> <1391183052.90077969.1447764792244.JavaMail.zimbra@uoguelph.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 17, 2015 at 07:53:12AM -0500, Rick Macklem wrote:

> > 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.

Ahh, this is option for NFSv4!
I think this sentention must be added to man page.
I will be knotty senetetion about NFSv4 don't used mount in general
and also possibility to disable NFSv2. I think about possibility to
disable NFSv3. May bad.

May be this is need to clarify in man page too?

> 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.;-)

I am talk only about man page description.

> 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.

My english wery bad for suggestion.

> 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@freebsd.org mailing list
> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > > > > To unsubscribe, send any mail to
> > > > > > "freebsd-hackers-unsubscribe@freebsd.org"
> > > > > > 
> > > > _______________________________________________
> > > > freebsd-hackers@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > > > To unsubscribe, send any mail to
> > > > "freebsd-hackers-unsubscribe@freebsd.org"
> > > > 
> > _______________________________________________
> > freebsd-hackers@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> > 



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