This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option


Grr.  Fsck'ing gmail reply to all.


---------- Forwarded message ----------
From: Chuck Lever <chucklever@gmail.com>
Date: Sat, Dec 18, 2010 at 8:19 PM
Subject: Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to
provide finer-grained security controls than offered by the -i option
To: "Andrew J. Schorr" <ajschorr@alumni.princeton.edu>


Hi Andrew-

On Sat, Dec 18, 2010 at 6:55 PM, Andrew J. Schorr
<ajschorr@alumni.princeton.edu> wrote:
> On Sat, Dec 18, 2010 at 06:44:59PM -0500, Jeff Layton wrote:
>> I can see arguments for either way. On the one hand, people porting to
>> libtirpc are likely to be fixing code anyway -- fixing this ought to be
>> doable at the same time. It's really not hard to call setgroups to fix
>> up the groups list before you call this function.
>
> When I originally reported the security issue with rpcbind that the -i option
> opens up too many things, Chuck said it would be a simple recompile to build
> with libtirpc and obviate that problem.

And, it usually is that simple.

> But you seem to be saying that
> significant porting is required. ?Is there a document somewhere describing the
> issues that may arise in porting from glibc's rpc API to libtirpc?

I don't think Jeff is suggesting that a lot of porting effort is
needed. ?The setgroups fix is likely valid for any version of the RPC
API -- as you pointed out, many RPC implementations truncate the
groups list. ?It's interesting that you have never encountered the
converse problem (that some user notices that your application is
ignoring some of their supplemental groups).

> It took me quite some time to chase down this getgroups issue. ?My
> application SEGV'ed, and I ultimately tracked it down after a lot
> of guesswork. ?The incompatibilies might not be so bad if they were
> clearly documented somewhere -- perhaps /usr/share/doc/libtirpc/PORTING
> is needed?

We should probably think about that now that we are planning to offer
libtirpc as the main RPC implementation on Linux and other systems. ?I
suspect, though, that the list will shrink as we encounter these minor
issues and correct them.

--
"What is a pancake, if not a big, fluffy Eucharist?"
?-- Stephen Colbert



-- 
"What is a pancake, if not a big, fluffy Eucharist?"
?-- Stephen Colbert


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]