From: Steve Dickson <SteveD@redhat.com>
To: "Andrew J. Schorr" <ajschorr@alumni.princeton.edu>
Cc: Chuck Lever <chuck.lever@oracle.com>, linux-nfs@vger.kernel.org
Subject: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option
Date: Fri, 10 Dec 2010 08:52:01 -0500 [thread overview]
Message-ID: <4D023081.9050102@RedHat.com> (raw)
In-Reply-To: <20101210023847.GB15344@ti93.telemetry-investments.com>
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.
next prev parent reply other threads:[~2010-12-10 13:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 20:49 proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option Andrew J. Schorr
2010-12-09 21:41 ` Chuck Lever
2010-12-10 0:07 ` Steve Dickson
2010-12-10 2:38 ` Andrew J. Schorr
2010-12-10 13:52 ` Steve Dickson [this message]
2010-12-10 15:31 ` Chuck Lever
2010-12-10 15:37 ` Andrew J. Schorr
2010-12-10 16:39 ` Chuck Lever
2010-12-10 15:55 ` Steve Dickson
2010-12-10 17:01 ` Chuck Lever
2010-12-10 17:07 ` Steve Dickson
[not found] ` <4D025E60.8030204-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2010-12-10 17:09 ` Chuck Lever
2010-12-10 17:10 ` Andrew J. Schorr
2010-12-10 17:14 ` Chuck Lever
2010-12-10 21:57 ` Andrew J. Schorr
[not found] ` <20101210215758.GA15059-RxCcQp2DQEZ/AkJ0XP51flIRPycPq0EMEZnpZpl6OOE@public.gmane.org>
2010-12-10 22:18 ` Chuck Lever
2010-12-10 22:22 ` Chuck Lever
2010-12-10 22:30 ` Andrew J. Schorr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D023081.9050102@RedHat.com \
--to=steved@redhat.com \
--cc=ajschorr@alumni.princeton.edu \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.