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 Sat, 18 Dec 2010 15:43:54 -0500
Chuck Lever <chucklever@gmail.com> wrote:

> 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?
> 

Yes, we did discuss this at Connectathon with Peter. I've cc'ed him
here. The BZ was here:

    https://bugzilla.redhat.com/show_bug.cgi?id=565507

The patch to remove the abort() calls is in the libtirpc git tree as
commit 89323aafc77e1a40800332fb135888782b1bfee6. I'm not sure why it's
not in Andrew's version -- maybe you can tell us which one you're using?

There was also a discussion on this list around mid-February last year
and we also talked about this in person at connectathon. At the time,
the decision was that returning NULL in this situation was the lesser
of two evils, and that glibc's behavior was a hack that creates its own
problems -- unpredictable behavior depending on whether the group your
application happens to need is in the list.

-- 
Jeff Layton <jlayton@redhat.com>


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