Chuck Lever wrote: > > Our port of rpcbind (from Sun) assumes this string contains a numeric > UID value, not alphabetical or symbolic characters, but checks this > value only for AF_LOCAL RPCB_SET or RPCB_UNSET requests. In all other > cases, rpcbind ignores the contents of the r_owner string. > Not that this makes the slightest difference to the usefulness of the patch, but it sounds like pretty strange behaviour for an rpcbind server to be using an incoming r_owner value off the wire under any circumstances. If I read the Irix and Solaris rpcbind source correctly, they will (sensibly, IMO) ignore incoming r_owner values in all cases. When an owner string is needed (during SET for storing in the internal data structure, and during UNSET for checking against the internal data structure) it is calculated from SVCXPRT itself and not from anything the client sends. The calculation returns one of: a) if the transport is over TLI loopback, a numerical representation of the peer process UID as reported by the special magical TLI kernel hack which reliably returns that, or b) if the transport is over IP and the peer port is privileged, the string "superuser", or c) otherwise, the string "unknown". AFAICS the only sensible use for the r_owner field is reporting the internally-calculated value back to the client, e.g. for the "rpcinfo -s" display. > The reference user space implementation of rpcb_set(3) uses a numeric > UID for all SET/UNSET requests (even via the network) and an empty > string for all other requests. We emulate that behavior here to > maintain bug-for-bug compatibility. > Fair enough. Reviewed-by: Greg Banks <gnb@xxxxxxx> -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. -- 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
