Interesting failure with RPC state tracker

Interesting failure with RPC state tracker

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

I have been trying to get NFS to work through Netfilter with the rpc
mdoule in p-o-m/extra.

I have finally gotten it to work successfully, but the struggle I had
getting it to work had an interesting outcome.

The reason my initial attempts failed is because the RPC tracking module
depends on intercepting GETPORT calls and opening expectations on the
assumption that if a client asks for the port for a given service on a
given server, it will want to connect to it.

The problem that this causes with Linux's "mount" command is that the
mount command (in util-linux) does a RPC portmap "DUMP" (tcp:111 on the
server) just like "rpcinfo -p" does.  It then extracts the port number
from there.

If you put a rule in the filter to block access to the portmapper's TCP
port on the server, the above process fails and then normal RPC
processing continues, with a GETPORT call to determine the port number.

Thots?

b.

-- 
Brian J. Murrell <netfilter@interlinx.bc.ca>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]