nfs-utils.git/support/export, branch master

libexport.a: xtab.c no longer needs #include xmalloc.h

2012-12-12T15:32:28+00:00

Signed-off-by: Chuck Lever 
Signed-off-by: Steve Dickson

libexport.a: rmtab.c no longer needs #include xmalloc.h

2012-12-12T15:32:28+00:00

Signed-off-by: Chuck Lever 
Signed-off-by: Steve Dickson

mountd: Add exportent_release()

2012-10-22T13:44:02+00:00

Split out the logic that releases dynamically allocated data in an
exportent.  The junction resolution code will invoke this to clean
up the junction exportent once it has been dumped to the kernel.

Signed-off-by: Chuck Lever 
Signed-off-by: Steve Dickson

Exportfs crashes with long path

2012-10-15T17:07:41+00:00

Acked-by: Bruce Fields 
Signed-off-by: Steve Dickson

libexport.a: fix using bad index for loop at cltsetup()

2011-06-22T22:31:57+00:00

In cltsetup(), when checking the address, use clp's naddr for index,
instead of  cltarg's naddr, which it's always zero there.

Signed-off-by: Mi Jinlong 
Signed-off-by: Steve Dickson

nfs: fix host_reliable_addrinfo

2011-06-22T18:51:38+00:00

According to Neil Brown:

    The point of the word 'reliable' is to check that the name we get
    really does belong to the host in question - ie that both the
    forward and reverse maps agree.

    But the new code doesn't do that check at all.  Rather it simply
    maps the address to a name, then discards the address and maps the
    name back to a list of addresses and uses that list of addresses as
    "where the request came from" for permission checking.

This bug is exploitable via the following scenario and could allow an
attacker access to data that they shouldn't be able to access.

    Suppose you export a filesystem to some subnet or FQDN and also to a
    wildcard or netgroup, and I know the details of this (maybe
    showmount -e tells me) Suppose further that I can get IP packets to
    your server..

    Then I create a reverse mapping for my ipaddress to a domain that I
    own, say "black.hat.org", and a forward mapping from that domain to
    my IP address, and one of your IP addresses.

    Then I try to mount your filesystem.  The IP address gets correctly
    mapped to "black.hat.org" and then mapped to both my IP address and
    your IP address.

    Then you search through all of your exports and find that one of the
    addresses: yours - is allowed to access the filesystem.

    So you create an export based on the addrinfo you have which allows
    my IP address the same access as your IP address.

Fix this by instead using the forward lookup of the hostname just to
verify that the original address is in the list. Then do a numeric
lookup using the address and stick the hostname in the ai_canonname.

Reviewed-by: NeilBrown 
Signed-off-by: Jeff Layton 
Signed-off-by: Steve Dickson

nfs-utils: Remove all uses of AI_ADDRCONFIG

2010-11-01T12:05:14+00:00

It was reported that, if only "lo" is up,

  mount.nfs 127.0.0.1:/export /mount

fails with "Name or service not known".

"man 3 getaddrinfo" says this:

  If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
  addresses are returned in the list pointed to by res only if the
  local system has at least one IPv4 address configured, and IPv6
  addresses are only returned if the local system has at least
  one IPv6 address configured.

The man page oversimplifies here.  A review of glibc shows that
getaddrinfo(3) explicitly ignores loopback addresses when deciding
whether an IPv4 or IPv6 address is configured.

This behavior around loopback is a problem not just for mount.nfs,
but also for RPC daemons that have to start up before a system's
networking is fully configured and started.  Given the history of
other problems with AI_ADDRCONFIG and the unpredictable behavior it
introduces, let's just remove it everywhere in nfs-utils.

This fix addresses:

  https://bugzilla.linux-nfs.org/show_bug.cgi?id=191

Signed-off-by: Chuck Lever 
Signed-off-by: Steve Dickson

gcc complained:

2010-10-14T14:26:59+00:00

client.c: In function 'init_netmask6':
client.c:181:1: warning: no return statement in function returning
non-void

and Suse' build system complained

I: Program returns random data in a function
E: nfs-utils no-return-in-nonvoid-function client.c:181

when I built without --enable-ipv6

Reviewed-by: Chuck Lever 
Signed-off-by: NeilBrown 
Signed-off-by: Steve Dickson

export: Ensure that we free struct exportent->e_uuid

2010-10-14T14:26:58+00:00

Currently, the exportent->e_uuid is initialised in
support/nfs/exports.c:parseopts(), but it is never freed.

Also ensure that exportent->e_uuid is duplicated correctly in
dupexportent().

Adjusted to account for the new export_free() helper.

Also, e_uuid points to memory that is always allocated with strdup(3),
not with xstrdup().  Thus it must be freed via free(3) and not via
xfree().

Signed-off-by: Trond Myklebust 
Signed-off-by: Chuck Lever 
Signed-off-by: Steve Dickson

libexport.a: Enable IPv6 support in hostname.c

2010-09-16T18:33:51+00:00

If --enable-ipv6 is specified when building nfs-utils, libexport's
host_foo() helpers can now return both IPv4 and IPv6 addresses.

This means IPv6 presentation addresses and IPv6 DNS resolution
results are handled properly in the mountd cache and /etc/exports,
but does not yet enable IPv6 mountd listeners.

Signed-off-by: Chuck Lever 
Signed-off-by: Steve Dickson