From owner-freebsd-hackers@freebsd.org Tue Nov 17 12:53:16 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 7E5DBA310A7 for ; Tue, 17 Nov 2015 12:53:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) 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 4E570190A for ; Tue, 17 Nov 2015 12:53:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 4D9ADA310A6; Tue, 17 Nov 2015 12:53:16 +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 4D2AEA310A5 for ; Tue, 17 Nov 2015 12:53:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E2C3A1909 for ; Tue, 17 Nov 2015 12:53:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:Muy+bR+IhThhu/9uRHKM819IXTAuvvDOBiVQ1KB82+4cTK2v8tzYMVDF4r011RmSDdidtqMP17CempujcFJDyK7JiGoFfp1IWk1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXsq3G/pQQfBg/4fVIsYL+lR8iP3o/rjaibwN76XUZhvHKFe7R8LRG7/036l/I9ps9cEJs30QbDuXBSeu5blitCLFOXmAvgtI/rpMYwu3cYhvQ66sQVUbnmZ79qCvtcDS86KCY7/sDmvwLPCwyV6TwZW2QSlxNORAzE9w37WJn29SXgu+d3wyXfPcT9Tr0uQmef6bx2QkrolDsfLGx+t2XWkdBryqxBrR+rvBA5xJTbJ4ScNf57d6WaedIBWWtHUMEWWTZMD4mnY84PBuECMPxD/LX68mAKpAS3TS6oBOTxwT9FgHzxw+VuyOA+ORPWzUo7B9hIqmmC//vvM6JHa+G+z+HtxD7Aa/5TkWPn7YHDcRQspNmRWr1tfM7JyQ8kHlWW3R2rtYX5MmbNhaw2uG+B4r84WA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CAAgCVIktW/61jaINehA4sAUIGvloBDYEIBFkXCoUlSgKCAxQBAQEBAQEBAYEJgi2CBwEBAQMBAQEBICsgCxACAQgOBAYCAg0EAQETAgInAQkYDgIECAcEARwEiAUIDQOrI5BCAQEBAQEBBAEBAQEBAQEYBIEBhVOEfoQ0BwEBBVgJAYJRgUQFjhGIOIUhgm8HgiokhCGHZYoxiFICHwEBQoIOAx2BdCA0B4M5AgcXI4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,307,1444708800"; d="scan'208";a="250902352" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 17 Nov 2015 07:53:13 -0500 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id C69D515F565; Tue, 17 Nov 2015 07:53:13 -0500 (EST) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id u504fp2c1Ap4; Tue, 17 Nov 2015 07:53:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 83E6815F56D; Tue, 17 Nov 2015 07:53:12 -0500 (EST) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dxYJf4HvcLGn; Tue, 17 Nov 2015 07:53:12 -0500 (EST) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 6791C15F565; Tue, 17 Nov 2015 07:53:12 -0500 (EST) Date: Tue, 17 Nov 2015 07:53:12 -0500 (EST) From: Rick Macklem To: Slawa Olhovchenkov Cc: hackers@freebsd.org Message-ID: <1391183052.90077969.1447764792244.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <20151117051820.GD31314@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> Subject: Re: NFSv4 details and documentations MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: NFSv4 details and documentations Thread-Index: tXGd0bKxhXmKH5JBXNlzWO4W6/MRWw== 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 12:53:16 -0000 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@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" >