On Dec 10, 2010, at 10:37 AM, Andrew J. Schorr wrote: > 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. To be clear, I'm not the rpcbind maintainer, so Steve can decide to take a patch anyway. > 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). Welcome to Linux. Changing glibc is viewed by some as an exceptionally challenging political task, which is why RPC hasn't been removed from it. I quite agree that now that we have libtirpc, RPC should be removed from glibc. -- 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
