On Fri, Dec 10, 2010 at 10:31:52AM -0500, Chuck Lever wrote: > > Not to put to fine a point on it, but we discourage the use of indirect RPC calls. It's a well-known security hole. Also, allowing anyone to set and unset RPC registrations is also insecure, and is discouraged. > > In general we want people to switch to using AF_UNIX for local registrations, as that is secure from remote attack, and allows rpcbind to assign ownership of the registration so that only the user who registered that service may unregister it. > > > So I would argue that the patch is still a good thing, but I agree that > > I should relink my code with libtirpc. > > IMO we shouldn't add features that encourage people to configure rpcbind insecurely, especially when there are reasonable alternatives. Well, if the patch won't be accepted, I will not put any more time into it. But I do have one question: if glibc's RPC routines are deprecated in favor of libtirpc, why not either remove the RPC code from glibc or at least mark these functions deprecated so that people get warning messages when they rebuild code (i.e. use __attribute__ (( __deprecated__ )) for all the functions declared in /usr/include/rpc/*.h)? There does not seem to be great documentation about this change for ignorant users such as myself (who just upgraded Fedora distros and unknowingly relinked with glibc instead of libtirpc). Regards, Andy -- 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
