On 12/09/2010 09: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.
>
> So I would argue that the patch is still a good thing, but I agree that
> I should relink my code with libtirpc.
If you decide to officially resubmit the patch please
1) Please sign you patch with a Signed-off-by: line as
described in:
http://www.linuxtv.org/wiki/index.php/Development:_Submitting_Patches
2) Also include a separate patch that updates the manual page.
(I can help with the nroff formatting).
tia,
steved.
--
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
