Re: [PATCH] mount.nfs: set the default family for lookups based on Defaultproto= setting

[Chuck Lever <chuck.lever@oracle.com>]

On 02/05/2010 02:55 PM, Jeff Layton wrote:
> On Fri, 5 Feb 2010 13:17:57 -0500
> Jeff Layton<jlayton@redhat.com>  wrote:
>
>>>> I can sort of buy the argument for leaving out the earlier #ifdef
>>>> around the default_value() function.
>>>>
>>>> If you change this one though, then lookups will still return IPv6
>>>> addresses by default even when IPV6_SUPPORTED isn't set. IOW, in the
>>>> absence of a proto= option, you'll pass AF_UNSPEC to getaddrinfo and
>>>> get IPv6 addresses. I don't think that's what we want here for a
>>>> non-ipv6 enabled nfs-utils.
>>>
>>> OK, agreed.  This setting is actually not determining the meaning of any
>>> of the netids, but rather it is determining the default address family
>>> if _no_ netid is specified.
>>>
>>
>> Correct. Ok, I'll respin and repost with the ifdef's in default_value()
>> removed.
>
> New patch sent. Just for giggles, I tested this by building a
> tirpc-enabled/ipv6-disabled nfs-utils and setting Defaultproto=tcp6. It
> does indeed set the address family to IPv6:
>
> # mount -v opensolaris:/export/public /mnt/test
> mount: no type was given - I'll assume nfs because of the colon
> mount.nfs: timeout set for Fri Feb  5 14:51:01 2010
> mount.nfs: trying text-based options 'vers=4,addr=feed::23,clientaddr=feed::22'
>
> ...and the mount succeeds.
>
> So in that situation and also when proto=tcp6 is specified, someone can
> mount an IPv6-capable server even with a nfs-utils that isn't built for
> IPv6 as long as it has tirpc support.
>
> Is that a good thing? I'm not sure -- statd won't work over IPv6 in
> that case, for instance. Would it be better to have mount.nfs fail to
> use IPv6 addrs at all when not built with IPv6 support?

If IPv6 support is disabled at build time, mount.nfs shouldn't allow a 
mount over IPv6, even if the kernel supports it.

Is that with, or without, my additional protocol family negotiation patches?

-- 
chuck[dot]lever[at]oracle[dot]com