Showmount itself tries to use a short timeout but
the RPC clnttcp_create and clntudp_create calls will call portmap
internally to get the port to use if it is set to 0 in the passed
address structure. The above calls then use the internal timeouts,
basically 60 seconds, which slows things down. Also the for tcp a
blocking connect is used which can take quite a while to timeout as
well.

showmount tries tcp then udp so a fail can go through several lengthy
waits before failing.

I've grabbed some of the autofs code and put together a patch to allow
specification of the timeouts for the portmap getport and to implement a
non-blocking connect.

For those that want "traditional" showmount -a behavior from their mountd
(hostname:/path instead of ipaddr:/path). This patch adds a '-r' flag that
does a reverse-resolve for each IP address listed in the rmtab when
a dump operation is called.

Probably not a good idea for those concerned about performance, but since it's
not the default option, I don't see it being an issue.

Neil suggested a patch to change the mountlist_add and mountlist_del calls to
use IP addresses instead of the names returned by client_compose based on a
command line option flag.

I don't see any real reason to put client_compose strings into the rmtab, so
this patch makes it so that it adds IP addresses instead of those strings to
the rmtab by default.

It also removes all mountlist_add calls that are being done from kernel cache
routines. My main concern there is NFSv4. We don't seem to make any upcalls to
mountd on NFSv4 unmounts, and I don't see a way to reliably remove NFSv4
entries. So, I figured I'd stick with having mountlist_add only called when
a v2 or v3 mount call is made, and mountlist_del called only on the
corresponding unmount call.

Here's a new set of patches to fix up "showmount -a", based on the approach
suggested by Neil. This first patch is fairly simple. It just stops
the current caching of my_client.

For an explanation, consider this situation with the current code:

1) Client mounts an NFS export from server that is restricted to a particular
hostname or netgroup.

2) DNS or netgroup changes so that the client would be denied.

3) Client attempts mount again. Mount succeeds, even though it shouldn't due
to the fact that mountd relies on cached info in my_client.

This situation can occur as long as no other client attempts a mount between
1 and 3 above. The patch below removes this caching, and causes a new
invocation of client_compose for each pass through auth_authenticate:

I noticed some mtab corruption the other day when doing some autofs
testing but thought nothing of it.

When investigating another issue I came across utils/mount.c:add_mtab
which looks like it adds an entry to /etc/mtab without performing
correct locking. Perhaps this is not needed when adding entries but I
think it is.

The getopt_long() option string in mountd was having a spurious
colon after the 'n', leading to the short form of --no-tcp not
being usable (expecting a parameter, contrary to the long form
and the documentation). Fix.

The exports(8) man page already mentions that some non-root users,
such as bin, might be just as sensitive as root, and that root_squash
thus might not be as effective as one could hope for. Update the
documentation to also mention that this could be the case for non-root
groups, such as staff.

Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
We've been ignoring all mapping errors and instead mapping to a "nobody" user
or group.

This is arguably OK for the cases where we're returning a value to the user
(so, id->name mapping on the server or name->id mapping on the client).

But it's a disaster in the other direction (id->name on the server or id->name
on the client): for example, a chown to an unknown user should *not*
automatically be translated into a succesful chown to "nobody".