Date: Tue, 12 Feb 2013 23:38:10 +0800 From: =?ISO-8859-1?Q?Elias_M=E5rtenson?= <lokedhs@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-current@freebsd.org Subject: Re: Possible bug in NFSv4 with krb5p security? Message-ID: <CADtN0WKGe5-z6ap3sdY2spsTDagh1zZhMJN9_Mc4JSy3Cac5Ew@mail.gmail.com> In-Reply-To: <1940678110.2931784.1360682456331.JavaMail.root@erie.cs.uoguelph.ca> References: <CADtN0WKbLoUUi_FLe2H_7tFThbmt9_pezA4vyR_-72zoVyzRmw@mail.gmail.com> <1940678110.2931784.1360682456331.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 February 2013 23:20, Rick Macklem <rmacklem@uoguelph.ca> wrote: There is (in case you missed it on google): > http://code.google.com/p/macnfsv4/wiki/FreeBSD8KerberizedNFSSetup > (Nothing much has changed since FreeBSD8, except the name of the client > side patch for host based initiator credentials in the keytab file.) > I was hoping others would add/update the wiki and it would eventually > become FreeBSD doc, but that hasn't happened. > > Thank you for the link. I have indeed found that, and I have followed it to the letter. I have up the exact same thing from Ubuntu machines as well as from Solaris, and I do have a fairly good understanding of Kerberos. FreeBSD however, is pretty new to me. > Other than that, the various discussions in the archive on this list > may help. Unfortunately, I don't know of an easy way to figure out > what is busted. I always suggest looking at the packets in wireshark, > but for some reason, I get the impression that folk don't like > doing this? It is what I do first when I run into NFS issues. > I've been looking at the dumps using Wireshark. Well, I had to drop down the security since everything is encrypted when using keb5p. I do get the same errors using sec=krb5. When looking at this trace, I see a normal OPEN request followed by a NFS4ERR_ACCESS as a reply. The Kerberos credentials are of course encrypted, so I can't really say anything about that part. Note that NFS4 with Kerberos security never uses the user ID numbers. They purely use the Kerberos principals for authorisation. This is different from the default "sys" security model that blindly uses user ID's. > > nfscbd_enable="YES" > Needed for client side only, and only if delegations are > enabled at the server and you want the client to acquire > delegations. (Delegations are not enabled by default on the > FreeBSD NFSv4 server.) > Noted. Thank you. I will change this. > > rpc_lockd_enable="YES" > > rpc_statd_enable="YES" > You shouldn't need rpc_lockd or rpc_statd for NFSv4, > since they are only used for NFSv3. > Good point. I'll disable those too. > I don't know why a Linux client would mix NFSv3 RPCs with NFSv4 ones, > I was suggested to set vfs.nfsd.server_min_nfsvers to 4 in order to completely disable NFS version below 4. I did this and got rid of the stray NFS3 requests. It didn't solve the original problem though. > > If anyone is able to confirm whether or not this actually has been > > tested > > in 9.1-CURRENT, I'd appreciate it. Also, if not, then I'd love to know > > where I should start looking for a solution. I'm experienced in system > > level programming (having worked on Solaris at Sun in a previous > > life), but > > a pointer where to start would be helpful. > > > Usually, when everything is being done by "nobody", it indicates that > the mapping between <uid, gids> <-> name@domain isn't working correctly. > (Looking at the packets in wireshark, you need to look at the attributes > called Owner and Owner_Group to see what they are being set to.) > I actually doubt this. First of all, I have the correct idmapd setup working from FreeBSD to Ubuntu (I can see that since I can see the correct user names in "ls" even though the user ID's differ). On OSX I haven't got it to work yet. But, the behaviour is the same on both systems. This is actually expected, as the permission checks are orthogonal to the ID mapping. > The most common problem (since you do have nfsuserd running on the server) > is for the "domain" spec to be different between client and server. > FreeBSD's nfsuserd defaults to the domain part of the machine's hostname. > Linux's rpc.idmapd sets the domain from /etc/idmapd.conf (at least I think > that's what it is called) and many distros ship with it set to "my.domain" > or something like that. > Correct. I have set this correctly. I know this, since once I did, "ls" started giving me the correct user names. > As such, I'd start by checking the Linux client and seeing what it has for > the domain spec. in /etc/idmapd.conf. > > If you want to override the default for FreeBSD, there is a command line > option for nfsuserd to do this. I can't remember what it is, but "man > nfsuserd" > will give you the answer and it can be set in /etc/rc.conf using > nfsuserd_flags. > Thank you. I'm definitely willing to double-check this and I am not going to claim to know exactly what's going on in the realms of NFS security. :-) > If this is configured correctly, then looking at the packets in wireshark > is > the best starting point w.r.t. figuring out what is broken. I do limited > testing of this and it works for me. I don't know how many others use it, > although some definitely have fun getting it working. (Usually it is the > Kerberos part on the client side that causes the most grief.) > It certainly is fun. But it gets frustrating when one fights a single problem for weeks on end. Far too few shops use Kerberos though. Regards, Elias
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADtN0WKGe5-z6ap3sdY2spsTDagh1zZhMJN9_Mc4JSy3Cac5Ew>