On 07/28/11 01:33, Theo de Raadt wrote:
On 07/27/11 23:42, Nicholas Marriott wrote:
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.
Unfortunately it isn't supposed to work that way.
^^^^^^^^^^^^^
That it is not supposed to work that way doesn't mean that it won't
work that way.
It could even work _better_ in another way. As you say yourself, ntpd
does have a fixed port number (2049). Why not allow (not enforce)
similar behaviour for mountd, too? It would have some advantages.
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.
I don't think clients need this functionality, they can still ask the
portmapper as they always did. My intention was not to redesign NFSv3
(that would be NFSv4), but to improve it's maintainability where it can
be done without breaking anything.
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.
I understand this principle of randomization and its advantages for bug
hunting and security. But I don't see how this principle of
randomization could yield anything in this setting of randomized ports
for mountd, which are discoverable via portmap anyway. There are no
established ports for mountd and it doesn't look like default ports
will be established for mountd, so no stupid assumptions to catch here.
Do you see any disadvantages in using fixed ports ?
Do you see any serious enought advantages in randomizing port
assignments to RPC services to justify enforcing this behaviour?
Cheers,
Christopher
