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

[Chuck Lever <chucklever at gmail dot com>]

Hi Andrew-

On Sat, Dec 18, 2010 at 2:12 PM, Andrew J. Schorr
<ajschorr@alumni.princeton.edu> wrote:
> On Mon, Dec 13, 2010 at 10:29:54AM -0500, Chuck Lever wrote:
>> There may be some minor ABI incompatibilities with the libtirpc
>> implementation of the legacy RPC API. ?This is no more serious in my
>> view than revving glibc and finding a bug or incompatibility in its
>> RPC implementation.
>
> Perhaps it depends how one defines minor. ?I just spent an hour
> debugging an incompatibility between glibc and libtirpc.
> In libtirpc:src/auth_unix.c:authunix_create_default(), there is the
> following code:
>
> ? ? ? ?if ((len = getgroups(NGRPS, gids)) < 0)
> ? ? ? ? ? ? ? ?abort();
>
> And in auth_unix.h, NGRPS is defined to be 16. ?Consequently, if a user
> belongs to more than 16 supplemental groups and tries to run some code
> that uses auth_unix credentials, the program crashes.
>
> I should mention that the Fedora rpm includes a patch that returns
> NULL instead of calling abort(). ?But nonetheless, the code does not work.

You are asking libtirpc to do something that the glibc implementation
allowed but should not have.

When we investigated this problem (and I think I remember talking with
Jeff Layton and Peter Staubach about this at Connectathon 2010), we
determined that glibc allowed more supplemental groups than the
protocol and other implementations can support.  Sixteen is the
standard limit.  If your application needs to communicate a longer
list of supplemental groups, it should be using RPCSEC GSS.

IIRC, this is why we took the approach of keeping the group limit in
the libtirpc implementation.  The glibc implementation is incorrect to
allow more than 16 supplemental groups.

Maybe Jeff can remember more about what we were thinking at the time.
Jeff, do you recall the bz number?  Do you know why Fedora has this
patch but upstream does not?

> If you look at the "legacy" glibc version of this funcion, you will
> see that the code works around this by first calling getgroups with a size
> of zero to ascertain how many group memberships there are. ?It then uses
> alloca to get a vector of the appropriate size.
>
> So this looks to me like a regression in libtirpc. ?Is this the best
> place to report the problem?

This is a fine place to report it.

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