Re: Different sequence of "exportfs" produce different effects on nfs client mounts

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 12129 bytes --]

On Thu, 17 Oct 2013 09:14:02 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi-
> 
> 281         if (ident[0] == '\0')
> 282                 return MCL_ANONYMOUS;
> 283         if (ident[0] == '@') {
> 284 #ifndef HAVE_INNETGR
> 285                 xlog(L_WARNING, "netgroup support not compiled in");
> 286 #endif
> 287                 return MCL_NETGROUP;
> 288         }
> 289         for (sp = ident; *sp; sp++) {
> 290                 if (*sp == '*' || *sp == '?' || *sp == '[')
> 291                         return MCL_WILDCARD;
> 292                 if (*sp == '/')
> 293                         return MCL_SUBNETWORK;
> 294                 if (*sp == '\\' && sp[1])
> 295                         sp++;
> 296         }
> 
> is still in play today.  The "host_pton()" code you posted was added by commit 502edf1d just after this paragraph.  But here is what that commit replaced.
> 
> -       /* check for N.N.N.N */
> -       sp = ident;
> -       if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_FQDN;
> -       sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> -       sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '.') return MCL_F
> -       sp++; if(!isdigit(*sp) || strtoul(sp, &sp, 10) > 255 || *sp != '\0') return MCL_
> -       /* we lie here a bit. but technically N.N.N.N == N.N.N.N/32 :) */
> -       return MCL_SUBNETWORK;
> +
> +       /*
> +        * Treat unadorned IP addresses as MCL_SUBNETWORK.
> +        * Everything else is MCL_FQDN.
> +        */
> +       ai = host_pton(ident);
> +       if (ai != NULL) {
> +               freeaddrinfo(ai);
> +               return MCL_SUBNETWORK;
> +       }
> +
> +       return MCL_FQDN;
>  }
> 
> The replaced logic also treats IP addresses as MCL_SUBNETWORK.  That's from commit 54669c98 in 2005.  Neil, do you remember why this semantic change was made?
> 

See this thread:

  http://marc.info/?t=110993941000003&r=1&w=2

It was a simple (though possibly flawed) solution to clearly differentiate
those addresses where DNS looked might be needed, and those where it was not.

I may have more to say later but I have to rush off now, so thought I'd just
post this anyway.

NeilBrown


> 
> 
> On Oct 17, 2013, at 3:16 AM, Wangminlan <wangminlan@huawei.com> wrote:
> 
> > Hi, 
> > 	I went through the code of nfs-utils, check the function client_gettype in support/export/client.c:
> > in nfs-utils-1-2-9-rc6, and in nfs-utils-1.2.6, they have this implementation in the final part:
> > 770         /*
> > 771          * Treat unadorned IP addresses as MCL_SUBNETWORK.
> > 772          * Everything else is MCL_FQDN.
> > 773          */
> > 774         ai = host_pton(ident);
> > 775         if (ai != NULL) {
> > 776                 freeaddrinfo(ai);
> > 777                 return MCL_SUBNETWORK;
> > 778         }
> > 779 
> > 780         return MCL_FQDN;
> > 781 }
> > 
> > while back in days of nfs-utils-1.0.7: client_gettype looks like this:
> > 277 client_gettype(char *ident)
> > 278 {
> > 279         char    *sp;
> > 280 
> > 281         if (ident[0] == '\0')
> > 282                 return MCL_ANONYMOUS;
> > 283         if (ident[0] == '@') {
> > 284 #ifndef HAVE_INNETGR
> > 285                 xlog(L_WARNING, "netgroup support not compiled in");
> > 286 #endif
> > 287                 return MCL_NETGROUP;
> > 288         }
> > 289         for (sp = ident; *sp; sp++) {
> > 290                 if (*sp == '*' || *sp == '?' || *sp == '[')
> > 291                         return MCL_WILDCARD;
> > 292                 if (*sp == '/')
> > 293                         return MCL_SUBNETWORK;
> > 294                 if (*sp == '\\' && sp[1])
> > 295                         sp++;
> > 296         }
> > 297         return MCL_FQDN;
> > 298 }
> > 
> > It's simple, and client like "192.168.0.21" is treated as MCL_FQDN. 
> > I tried the same operation in this version, there's no such problem as in nfs-utils-1.2.1 and nfs-utils-1.2.6.
> > 
> >> -----Original Message-----
> >> From: linux-nfs-owner@vger.kernel.org
> >> [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of Wangminlan
> >> Sent: Wednesday, October 16, 2013 9:23 AM
> >> To: J. Bruce Fields
> >> Cc: linux-nfs@vger.kernel.org
> >> Subject: RE: Different sequence of "exportfs" produce different effects on nfs
> >> client mounts
> >> 
> >> Hi, Bruce,
> >> 	The nfs-utils on my box is nfs-utils-1.2.1-2.6.6, which is Suse distributed.
> >> 	I tried the same experiment on fedora18, which use nfs-utils-1.2.6, and
> >> got the same result.
> >> 	I go through the code of support/export/client.c, found that in
> >> client_get_type(), when the client is specified as an IP address(which can not
> >> be resolved as an FQDN), it actually return the result: MCL_SUBNETWORK.
> >> 	I guess that's the reason that the client "192.168.0.21" and
> >> "192.168.0.0/16" both are sorted to the same category: MCL_SUBNETWORK,
> >> so the order of exports matters here.
> >> 	Is this what exportfs and mountd mean to be?
> >> B.R
> >> Minlan Wang
> >> 
> >> On Tuesday, October 15, 2013 at 03:49AM +0000, Bruce Fields wrote:
> >>> Looking at the mountd code....
> >>> 
> >>> Looks like utils/mountd/cache.c makes no special effort to prioritize
> >>> exports except in the v4root and crossmnt cases, neither an issue in
> >>> your case.
> >>> 
> >>> So yes it depends on ordering. From man exports:
> >>> 
> >>> 	 If a client matches more than one of the specifications above,
> >>> 	 then the first match from the above list order takes precedence
> >>> 	 - regardless  of the  order they appear on the export line.
> >>> 	 However, if a client matches more than one of the same type of
> >>> 	 specification (e.g.  two  netgroups), then  the  first  match
> >>> 	 from  the order they appear on the export line takes
> >>> 	 precedence.
> >>> 
> >>> The order given is: single host, IP networks, wildcards, negroups,
> >>> anonymous.
> >>> 
> >>> So the single host exports should have taken precedence.
> >>> 
> >>> The code here does look like it corectly implements the above ordering.
> >>> 
> >>> What version of nfs-utils are you using?
> >>> 
> >>> --b.
> >>> 
> >>> On Tue, Oct 15, 2013 at 06:39:59AM +0000, Wangminlan wrote:
> >>>> On Mon, Oct 14, 2013 at 16:46 +0000, Bruce Fields wrote:
> >>>>> On Mon, Oct 14, 2013 at 02:16:58AM +0000, Wangminlan wrote:
> >>>>>> 　　Hi,
> >>>>>> 　　         I’ve got a problem on the nfs exportfs command. I’m
> >>> not
> >>>>> sure if this is the right place to ask this, if not, can you please tell me
> >>> where?
> >>>>>> 
> >>>>>> 　　         Here’s what I need:
> >>>>>> 　　1. I have a folder named /mnt/fs1 to be exported.
> >>>>>> 　　2. All the host in subnetwork 192.168.0.0/16 should be able access
> >>> this
> >>>>> folder, but their root should be squashed.
> >>>>>> 　　3. Some specified host in the same subnetwork can gain the root
> >>>>> permission on the folder, for example: 192.168.0.21, 192.168.0.22.
> >>>>>> 
> >>>>>> 　　I’ve got a SLES11SP1 box as the nfs server, the nfs clients are
> >>> SLES11SP1,
> >>>>> too, and the protocol used between clients and server are NFSv3.
> >>>>>> 　　Here are the commands I used to do the export:
> >>>>>> 　　#exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
> >>>>>> 　　#exportfs –o rw,no_root_squash 192.168.0.21:/mnt/fs1
> >>>>>> 　　#exportfs –o rw,no_root_squash 192.168.0.22:/mnt/fs1
> >>>>>> 　　After this, everything works as expected.
> >>>> After this, the contents of /proc/net/rpc/auth.unix.ip/content and
> >>> /proc/net/rpc/nfsd.export/content are:
> >>>> 	NV200_01:/proc/net/rpc # cat auth.unix.ip/content
> >>>> 	#class IP domain
> >>>> 	nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
> >>>> 	nfsd 0.0.0.0 -test-client-
> >>>> 	# nfsd 100.43.189.1 -no-domain-
> >>>> 
> >>>> 	NV200_01:/proc/net/rpc # cat nfsd.export/content
> >>>> 	#path domain(flags)
> >>>> 	/mnt/fs1
> >>> 	-test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967
> >>> 295,anongid=4294967295)
> >>>> 	/mnt/fs1
> >>> 	192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree
> >>> _check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> >>>> 	# /mnt/fs1
> >>> 	192.168.0.0/16,192.168.0.21(rw,no_root_squash,sync,wdelay,no_subtree
> >>> _check,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> >>>> Besides, the content of /var/lib/nfs/etab is:
> >>>> 	NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
> >>>> 	/mnt/fs1
> >>> 	192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>> 
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>> 	/mnt/fs1
> >>> 	192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>> 
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>> 	/mnt/fs1
> >>> 	192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_
> >>> 
> >> all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534
> >>> )
> >>>>>> 
> >>>>>> 　　But, after the following operations:
> >>>>>> 　　#exportfs –u 192.168.0.0/16:/mnt/fs1              /* Delete
> >>> this
> >>>>> export */
> >>>>>> 　　# exportfs –o rw,root_squash 192.168.0.0/16:/mnt/fs1
> >>> /*
> >>>>> And add it again */
> >>>>>> 　　Hosts on 192.168.0.21 and 192.168.0.22 doesn’t get root
> >>> permission
> >>>>> any more. when I tried to write a file, it complains about “Permission
> >>> denied”.
> >>>>>> 
> >>>>>> 　　So, does the order of exportfs command has something to do the
> >>> final
> >>>>> result? Or am I doing something wrong?
> >>>> After this, the contents of /proc/net/rpc/auth.unix.ip/content and
> >>> /proc/net/rpc/nfsd.export/content are:
> >>>> 	NV200_01:/proc/net/rpc # cat auth.unix.ip/content
> >>>> 	#class IP domain
> >>>> 	nfsd 192.168.0.21 192.168.0.0/16,192.168.0.21
> >>>> 	nfsd 0.0.0.0 -test-client-
> >>>> 	# nfsd 100.43.189.1 -no-domain-
> >>>> 
> >>>> 	NV200_01:/proc/net/rpc # cat nfsd
> >>>> 	nfsd         nfsd.export/ nfsd.fh/
> >>>> 	NV200_01:/proc/net/rpc # cat nfsd
> >>>> 	nfsd         nfsd.export/ nfsd.fh/
> >>>> 	NV200_01:/proc/net/rpc # cat nfsd.export/content
> >>>> 	#path domain(flags)
> >>>> 	/mnt/fs1
> >>> 	-test-client-(rw,no_root_squash,sync,no_wdelay,fsid=0,anonuid=4294967
> >>> 295,anongid=4294967295)
> >>>> 	/mnt/fs1
> >>> 	192.168.0.0/16,192.168.0.21(rw,root_squash,sync,wdelay,no_subtree_ch
> >>> eck,uuid=13266f0d:1fbd40d5:b0b5c4fe:cfe104eb)
> >>>> And the content of /var/lib/nfs/etab is:
> >>>> 	NV200_01:/proc/net/rpc # cat /var/lib/nfs/etab
> >>>> 	/mnt/fs1
> >>> 	192.168.0.0/16(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_
> >>> 
> >> all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534
> >>> )
> >>>> 	/mnt/fs1
> >>> 	192.168.0.22(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>> 
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>> 	/mnt/fs1
> >>> 	192.168.0.21(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no
> >>> 
> >> _all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=6553
> >>> 4)
> >>>>> 
> >>>>> That sounds like a bug.  The contents of
> >>>>> /proc/net/rpc/auth.unix.ip/content and
> >> /proc/net/rpc/nfsd.export/content
> >>>>> after getting the above "permission denied" might be interesting.
> >> \x13��칻\x1c�&�~�&�\x18��+-��ݶ\x17��w��˛���m�b��g~ȧ�\x17��ܨ}���Ơz�&j:+v���
> >> 
> > ����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[f
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]