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
On Sat, Dec 18, 2010 at 4:08 PM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> On Sat, Dec 18, 2010 at 03:43:54PM -0500, Chuck Lever wrote:
>> 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.
>
> getgroups returns "the supplementary group IDs of the calling
> process". ?It's not up to the application how many there are.
To be more precise, a particular application may rely on the group
permissions, or it may not. If it does rely on them, and expects to
run on systems where users regularly have greater than 16 supplemental
groups, then it should be built to use a modern mechanism for
communicating authentication and authorization information.
The 16 group limit for AUTH_SYS is well known. On Linux we happen to
paper over it for user space applications using the glibc RPC
implementation. It's not a portable solution, but I believe that was
all that was available when this implementation was written years ago.
> So the actual scenario is that if the user belongs to more than 16
> groups, anything that uses this code will crash. ?Doesn't that seem
> like a pretty big problem?
Yes, that's why we removed the abort() calls in the Fedora libtirpc
RPM. I'm not sure why that fix has not gone upstream yet, but we can
still revisit the exact solution if it is not strong enough.
The problem is what do you do instead of crashing, in that case?
Truncating the group list is a hidden bug as well. Sending more than
16 groups is likely going to cause either a crash or truncation on the
server end. I seem to recall there was no clear way to return an
error code through this particular RPC API, but I might be mistaken.
--
"What is a pancake, if not a big, fluffy Eucharist?"
?-- Stephen Colbert