Linux NFS development
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Peter Staubach <staubach@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>,
	steved@redhat.com, libtirpc-devel@lists.sourceforge.net,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH] libtirpc: handle large numbers of supplemental groups gracefully (try #2)
Date: Tue, 16 Feb 2010 14:25:43 -0500	[thread overview]
Message-ID: <4B7AF137.6090008@oracle.com> (raw)
In-Reply-To: <4B7AF0D9.4030208@redhat.com>

On 02/16/2010 02:24 PM, Peter Staubach wrote:
> Jeff Layton wrote:
>> This is the second attempt at this patch. The main changes are that this
>> one doesn't set a floor value for the size of the group list. There are
>> also a few minor cleanups and comments added.
>>
>> If authunix_create_default() is called by a user with more than 16
>> supplimental groups, it'll abort(), which causes the program to crash
>> and coredump.
>>
>> Fix it to handle this situation gracefully. Get the number of groups
>> that the user has first, and then allocate a big enough buffer to hold
>> them. Then, just don't let the lower function use more than the NGRPS
>> groups.
>>
>> Also fix up the error handling in this function so that it just returns
>> a NULL pointer on error and logs a message via warnx() instead of
>> calling abort().
>>
>> Reported-by: Peter Engel<peter.engel-y6kNeMnOB+c@public.gmane.org>
>> Signed-off-by: Jeff Layton<jlayton@redhat.com>
>> ---
>>   src/auth_unix.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++-----
>>   1 files changed, 56 insertions(+), 6 deletions(-)
>>
>> diff --git a/src/auth_unix.c b/src/auth_unix.c
>> index 71ca15d..a295e71 100644
>> --- a/src/auth_unix.c
>> +++ b/src/auth_unix.c
>> @@ -49,6 +49,7 @@
>>   #include<stdlib.h>
>>   #include<unistd.h>
>>   #include<string.h>
>> +#include<errno.h>
>>
>>   #include<rpc/types.h>
>>   #include<rpc/xdr.h>
>> @@ -175,20 +176,69 @@ AUTH *
>>   authunix_create_default()
>>   {
>>   	int len;
>> +	size_t bufsize = 0;
>>   	char machname[MAXHOSTNAMELEN + 1];
>>   	uid_t uid;
>>   	gid_t gid;
>> -	gid_t gids[NGRPS];
>> +	gid_t *gids = NULL;
>> +	AUTH *auth;
>> +
>> +	if (gethostname(machname, sizeof machname) == -1) {
>> +		warnx("%s: gethostname() failed: %s", __func__,
>> +			strerror(errno));
>> +		return NULL;
>> +	}
>>
>> -	if (gethostname(machname, sizeof machname) == -1)
>> -		abort();
>>   	machname[sizeof(machname) - 1] = 0;
>>   	uid = geteuid();
>>   	gid = getegid();
>> -	if ((len = getgroups(NGRPS, gids))<  0)
>> -		abort();
>> +
>> +retry:
>> +	len = getgroups(0, NULL);
>> +	if (len<  0) {
>> +		warnx("%s: failed to get number of groups: %s", __func__,
>> +			strerror(errno));
>> +		return NULL;
>> +	}
>> +
>> +	if (len == 0)
>> +		goto no_groups;
>> +
>> +	bufsize = len * sizeof(gid_t);
>> +	gids = mem_alloc(bufsize);
>> +	if (gids == NULL) {
>> +		warnx("%s: memory allocation failed: %s", __func__,
>> +			strerror(ENOMEM));
>> +		return NULL;
>> +	}
>> +
>> +	len = getgroups(len, gids);
>> +	if (len<  0) {
>> +		mem_free(gids, bufsize);
>> +		/*
>> +		 * glibc equivalent routines mention that it's possible for
>> +		 * the number of groups to change between two getgroups calls.
>> +		 * If that happens, retry the whole thing again.
>> +		 */
>> +		if (len == -EINVAL) {
>> +			gids = NULL;
>> +			bufsize = 0;
>> +			goto retry;
>> +		}
>> +		warnx("%s: failed to get group list: %s", __func__,
>> +			strerror(errno));
>> +		return NULL;
>> +	}
>> +
>> +	/* AUTH_UNIX has a hard limit of NGRPS supplemental groups */
>> +	if (len>  NGRPS)
>> +		len = NGRPS;
>> +
>> +no_groups:
>>   	/* XXX: interface problem; those should all have been unsigned */
>> -	return (authunix_create(machname, uid, gid, len, gids));
>> +	auth = authunix_create(machname, uid, gid, len, gids);
>> +	mem_free(gids, bufsize);
>> +	return auth;
>>   }
>>
>>   /*
>
> This change to restrict the groups used to the first NGRPS
> groups is one that we have always avoided.  It can be quite
> confusing to the user, to have an operation fail, but then
> to look and notice that the correct group is listed.
>
> Having the library abort seems odd and wrong, but this will
> also change semantics.  Is there really a problem here,
> after all of these years, that must be addressed?

We're actually copying semantics from glibc.   I think RPC applications 
on Linux might expect the glibc behavior.  Thoughts?

-- 
chuck[dot]lever[at]oracle[dot]com

  reply	other threads:[~2010-02-16 19:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-16 19:16 [PATCH] libtirpc: handle large numbers of supplemental groups gracefully (try #2) Jeff Layton
2010-02-16 19:22 ` Chuck Lever
2010-02-16 19:24 ` Peter Staubach
2010-02-16 19:25   ` Chuck Lever [this message]
2010-02-16 19:33   ` Jeff Layton
     [not found]     ` <20100216143307.45a7ed42-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-02-16 19:49       ` Peter Staubach
2010-02-16 20:10         ` Chuck Lever
2010-02-16 20:14         ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B7AF137.6090008@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=libtirpc-devel@lists.sourceforge.net \
    --cc=linux-nfs@vger.kernel.org \
    --cc=staubach@redhat.com \
    --cc=steved@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox