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. So I would argue that the patch is still a good thing, but I agree that I should relink my code with 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
