On Mar 11, 2009, at 3:06 PM, J. Bruce Fields wrote:
On Tue, Mar 03, 2009 at 05:33:25PM -0500, Chuck Lever wrote:
It turns out that, despite the spec, rpcbind interprets the string
Should someone be fixing rpcbind too?
Fix it how? The spec just says r_owner is a string. It doesn't
mandate a particular use for it, as far as I recall. I'm simply
matching up our current kernel rpcbind client with what we run in user
space at this point.
passed in the r_owner argument for SET and UNSET requests. It
expects
it to be a numeric UID, rather than an arbitrary string.
Change the kernel's r_owner string to be "0".
This is a documentation change only.
Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
---
net/sunrpc/rpcb_clnt.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
index 317eb8a..0a3b8f5 100644
--- a/net/sunrpc/rpcb_clnt.c
+++ b/net/sunrpc/rpcb_clnt.c
@@ -63,9 +63,11 @@ enum {
* r_owner
*
* The "owner" is allowed to unset a service in the rpcbind database.
- * We always use the following (arbitrary) fixed string.
+ * rpcbind maps this string to a local user name via a passwd lookup
+ * for AF_LOCAL SET/UNSET requests, but via the network (ie how the
+ * kernel registers its services) it is pretty much ignored.
*/
-#define RPCB_OWNER_STRING "rpcb"
+#define RPCB_OWNER_STRING "0"
#define RPCB_MAXOWNERLEN sizeof(RPCB_OWNER_STRING)
static void rpcb_getport_done(struct rpc_task *, void *);
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs"
in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
