> On 07/27/11 23:42, Nicholas Marriott wrote: > > Do you have a particular usage that needs this? > > No, I just run a local nfs server; at the moment only serving one > single, trusted client. > So I'm not in desperate need for fixed ports, but I think fixed ports > are a lot cleaner and over all easier to maintain.
RPC does not work that way. It uses the portmapper at port 111 for discovery. NFS at 2049 is also a known port. The rest are supposed to be unknown. > For example when I run a netstat -na, tcpdump or pf I want to be able > to recognize the ports I see and use. Unfortunately it isn't supposed to work that way. > Of course, Theo is right. I don't get a direct gain in security by > tightening up my firewall against trusted hosts which have NFS access > anyhow. But still the network as a whole gets more transparent and > maintainable. I know whats going on and I can easily block, allow or > inspect NFS and non-NFS traffic. Except that isn't how it is supposed to work with RPC. An extension of where you are going would be to add such functionality to every single program which uses RPC, either as a server or even as a client. And that is surely over the top. > One problem I haven't run into yet, but could imagine: Could the random > rpc services occupy a port, which services started later on, for example > cups (631 TCP), would need? No. This is handled in /etc/rc with the fill_baddynamic() function, the randomization avoids collisions against published port numbers. > Just out of curiosity, why those random port assignments in the first > place? Does this have or did it have any advantages? Maybe to be able > to run different versions of the same rpc server at the same time? We applied this as principle around 10 years ago. Anything which does not need to be sequential is random, just because developers make stupid assumptions and use them as ran.
