All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.