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]

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


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.

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?

Regards,
Andy


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