On Wednesday March 9, [email protected] wrote:
> >
> > It is only safe to avoid the DNS lookup if there are *no* names in the
> > /etc/exports file. If everything is one of "*", "ip.ad.dr.es" or
> > "ne.t-.wo.rk/mask" then it is OK, If there is any domain.name or
> > @netgroup, then you always need to find the name.
>
> What about '*.domain.name' style wildcards?
>
Yep, Always need DNS lookup if there are any of those too.
> > The problem arises if someone exports one filesystem to an IP address,
> > and another to the DNS name. Confusion and failure results.
>
> Like this? /etc/exports:
>
> /home 1.2.3.4(rw)
> /public joker(rw)
>
> What is the failure scenario? I don't quite understand where is the problem.
Suppose joker is 1.2.3.4
joker mounts '/home'. Mountd doesn't bother with the DNS lookup and
tell the kernel:
1/ IP address "1.2.3.4" has name "1.2.3.4"
2/ client with name "1.2.3.4" is allowed to access /home with
options "rw"
Then joker mounts '/public' so mountd need to do the DNS lookup, and
tells the kernel:
1/ IP address "1.2.3.4" has name "joker"
2/ client with name "joker" is allowed to access /public
with options "rw".
Now joker tries to access it's mount of /home, and this fails, because
1.2.3.4 maps to "joker", and "joker" doesn't have access to /home
For this reason, there must be a canonical name for each IP address.
This has always been:
DNS name if it exists, else dotted-quad
We could make it always
dotted-quad
but the former works better when you have multi-homed clients.
The compromise would be
If there are any names in /etc/exports and DNS name exists, use it,
else used dotted quad.
In 2.6, if /proc/fs/nfsd is mounted, the name used is a
comma-separated list of all names mentioned in /etc/exports which
match the IP address.
The same could possibly done for when /proc/fs/nfsd isn't mounted.
NeilBrown
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> > /home 1.2.3.4(rw)
> > /public joker(rw)
> >
> > What is the failure scenario? I don't quite understand where is the problem.
>
> Suppose joker is 1.2.3.4
>
> joker mounts '/home'. Mountd doesn't bother with the DNS lookup and
> tell the kernel:
>
> 1/ IP address "1.2.3.4" has name "1.2.3.4"
> 2/ client with name "1.2.3.4" is allowed to access /home with
> options "rw"
>
> Then joker mounts '/public' so mountd need to do the DNS lookup, and
> tells the kernel:
>
> 1/ IP address "1.2.3.4" has name "joker"
> 2/ client with name "joker" is allowed to access /public
> with options "rw".
>
> Now joker tries to access it's mount of /home, and this fails, because
> 1.2.3.4 maps to "joker", and "joker" doesn't have access to /home
Uggh.
BTW, I understood in-kernel NFS auth as follows:
RPC request came -> kernel translates sender's IP into name ->
kernel checks name against in-kernel export table for permissions
In-kernel export table gets (de)populated by mountd, as needed.
Correct me if I misunderstood something.
> For this reason, there must be a canonical name for each IP address.
> This has always been:
> DNS name if it exists, else dotted-quad
>
> We could make it always
> dotted-quad
Sounds very sensible. Will this allow us to skip IP->name
translation in kernel entirely?
> but the former works better when you have multi-homed clients.
By keeping in-kernel export table compact? This isn't big,
you rarely have hosts with 10+ heads. Any other reasons?
> The compromise would be
> If there are any names in /etc/exports and DNS name exists, use it,
> else use dotted quad.
>
> In 2.6, if /proc/fs/nfsd is mounted, the name used is a
> comma-separated list of all names mentioned in /etc/exports which
> match the IP address.
I see. I am getting familiar with how NFS internals work.
I exported / both to 127.0.0.1 and to localhost. Instrumented mountd says:
mountd: cache_export(): exp->m_client->m_addrlist[0]=127.0.0.1
mountd: cache_export(): exp->m_client->m_hostname=127.0.0.1,localhost
^^^^^^^^^^^^^^^^^^^
mountd: cache_export_ent(): domain=127.0.0.1,localhost
mountd: cache_export_ent(): exp->e_path=/
> The same could possibly done for when /proc/fs/nfsd isn't mounted.
--
vda
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs