Steve Dickson wrote:
>>>> I can't see why we need to refer back to either file to determine 
>>>> the transport protocol for a umount request.  Whatever transport 
>>>> mountd is advertising at the moment is what should be used, right?
>>> Well for firewall reasons you generally want to use the protocol
>>> that the mount used...
>>
>> That could have been a very long time ago, even months, and the server 
>> settings may have changed.  Thus sending what mount used seems 
>> inherently unreliable.  The race window is enormous!

> hmm... I must be missing something... Why is umount-ing with the
> same network protocol that mount used unreliable and racy?

Well, I exaggerated a bit, but technically speaking it is a race window 
because the client is caching information about the server.  When a 
mount succeeds, the client remembers the transport protocol it used for 
the mount in /etc/mtab.

A long time later, it uses that cached information to set the transport 
protocol for the umount request.

During the time the share is mounted (ie the window), some system 
administrator can change the server's settings -- for example, by 
disabling the TCP mountd service, or by changing the iptables on the 
server.  At that point, the information in the client's /etc/mtab 
becomes stale, and, in fact, useless as a hint.

I'm simply arguing that /etc/mtab should be ignored by umount entirely 
when it comes to determining what transport protocol to use because that 
cached information in not reliable.  Just do a fresh GETPORT before the 
umount, and you will be all set.