On 12/10/2010 12:01 PM, Chuck Lever wrote: > 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? I would guess for legacy reasons... I guess we could open an Fedora bz asking to disable the code... steved. > 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. > -- 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
