On Dec 10, 2010, at 12:07 PM, Steve Dickson wrote: > > > 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... Thanks, that would be an excellent first step. > 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. >> -- 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
