This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option
- From: "Andrew J. Schorr" <ajschorr at alumni dot princeton dot edu>
- To: Chuck Lever <chucklever at gmail dot com>
- Cc: Steve Dickson <SteveD at redhat dot com>, libc-alpha at sourceware dot org,libtirpc <libtirpc-devel at lists dot sourceforge dot net>
- Date: Sat, 18 Dec 2010 14:12:28 -0500
- Subject: Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option
- References: <4D0632C5.1040107@RedHat.com><AANLkTi=FNANqAs5m3xbZcQq5K0vMtZBb1+KU9pWC9K8_@mail.gmail.com>
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