From owner-freebsd-hackers@freebsd.org Tue Nov 17 17:09:28 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7205A310A6 for ; Tue, 17 Nov 2015 17:09:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BB0A41A70 for ; Tue, 17 Nov 2015 17:09:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id B740CA310A5; Tue, 17 Nov 2015 17:09:28 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5D71A310A4 for ; Tue, 17 Nov 2015 17:09:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 62C0B1A6F for ; Tue, 17 Nov 2015 17:09:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1Zyjkr-000O27-Ba; Tue, 17 Nov 2015 20:09:17 +0300 Date: Tue, 17 Nov 2015 20:09:17 +0300 From: Slawa Olhovchenkov To: Rick Macklem Cc: hackers@freebsd.org Subject: Re: NFSv4 details and documentations Message-ID: <20151117170917.GE31314@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> <20151117051820.GD31314@zxy.spb.ru> <1391183052.90077969.1447764792244.JavaMail.zimbra@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1391183052.90077969.1447764792244.JavaMail.zimbra@uoguelph.ca> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 17:09:29 -0000 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" > >