Hi Steve- On Dec 10, 2010, at 10:55 AM, Steve Dickson wrote: > On 12/10/2010 10:31 AM, Chuck Lever wrote: >> >> On Dec 9, 2010, at 9:38 PM, Andrew J. Schorr wrote: >> >>> On Thu, Dec 09, 2010 at 07:07:32PM -0500, Steve Dickson wrote: >>>> >>>> >>>> On 12/09/2010 04:41 PM, Chuck Lever wrote: >>>>> It sounds like your application is trying to use glibc's RPC >>>>> implementation with rpcbind. If you build your application with >>>>> libtirpc instead, it should use an AF_UNIX socket to contact rpcbind >>>>> instead of loopback. The AF_UNIX socket carries some authentication >>>>> information with the registration request. All users of your >>>>> application would be allowed to set or unset RPC registrations >>>>> in that case. >>> >>> I think you are correct. This is probably due to some combination >>> of ignorance and stupidity on my part. I didn't realize that libtirpc >>> was a drop-in replacement for the glibc RPC routines. >>> >>>> I was under the impression rebuilding the applications was not >>>> possible... but maybe I misunderstood... >>> >>> Rebuilding should be possible, I need to look into this. >>> >>>> But in the end, I guess I'm not against having functionality >>>> like this... If it make it easier for people to port legacy >>>> applications to Linux, its probably a good thing... >>> >>> I think the patch does add more control over rpcbind behavior, but I >>> grant that it may be less interesting if nobody is using IP to connect >>> from local clients. Nonetheless, it still adds the ability to have >>> separate control over whether to accept remote set/unset calls and >>> whether to honor indirect/callit calls. Unless I'm mistaken, this is >>> still relevant even if libtirpc is used. >> >> 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. > True... but its been this way for years... and always will be... > >> 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. > If the option of rebuilding is available, yes, people should > switch to libtirpc... Andrew makes a good point. There would be no "switch to libtirpc" if distributions had a single RPC implementation. Is there a good reason we still have the glibc RPC implementation? We've resolved the licensing issue already, so there's nothing stopping any Linux distribution from adding a libtirpc package. > >>> 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. > The -i is already a securely hole... So if we are concern about it > we should get ride of the -i completely... Or make it a useful > securely hole... ;-) > > The point of this patch was to make it easier for people > to port legacy applications to Linux... If this indeed > is the case, I think that overrides these (self induced) > security issues... If we go with just the evidence at hand: Andrew says he can rebuild his application. Thus, so far there is no specific requirement to expand "-i". IMO we should wait until there is, in the most noble of Linux traditions. -- 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
