> So I still think that the reason for this is a check in the kernel, that
> prevents connections from ports > 1024.
Nope. It's the following hunk:
diff -ur -X dontdiff linux-2.4.9-18.3/net/sunrpc/pmap_clnt.c
linux-2.4.9-18.3-p3/net/sunrpc/pmap_clnt.c
--- linux-2.4.9-18.3/net/sunrpc/pmap_clnt.c Wed Jun 21 12:43:37 2000
+++ linux-2.4.9-18.3-p3/net/sunrpc/pmap_clnt.c Mon Jan 7 12:59:54 2002
@@ -189,7 +189,7 @@
struct rpc_clnt *clnt;
/* printk("pmap: create xprt\n"); */
- if (!(xprt = xprt_create_proto(proto, srvaddr, NULL)))
+ if (!(xprt = xprt_create_proto(proto, srvaddr, NULL, 0)))
return NULL;
xprt->addr.sin_port = htons(RPC_PMAP_PORT);
The above change implies that the portmapper can always be run from an
insecure port.
It can if the purpose of the RPC call is trying to read off a port number for
an RPC service. If the idea is to register a new service, however, then the
portmapper demands that we use a secure port.
The fix would be to add an argument to the function pmap_create() in order to
allow rpc_register() to specify that the call to xprt_create_proto() should
set up the socket on a secure port.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/