From dm@punish.uun.org Thu Aug 12 07:51:29 1999
Return-Path: <dm@punish.uun.org>
Received: from punish.uun.org (punish.uun.org [18.23.10.83])
	by hub.freebsd.org (Postfix) with ESMTP id 17FE114EDF
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 12 Aug 1999 07:51:26 -0700 (PDT)
	(envelope-from dm@punish.uun.org)
Received: (from dm@localhost)
	by punish.uun.org (8.9.1/8.9.1) id KAA19945;
	Thu, 12 Aug 1999 10:51:25 -0400 (EDT)
	(envelope-from dm)
Message-Id: <199908121451.KAA19945@punish.uun.org>
Date: Thu, 12 Aug 1999 10:51:25 -0400 (EDT)
From: David Mazieres <dm@eecs.harvard.edu>
Sender: dm@punish.uun.org
Reply-To: dm@eecs.harvard.edu
To: FreeBSD-gnats-submit@freebsd.org
Subject: authunix_create_default inconsistent
X-Send-Pr-Version: 3.2

>Number:         13108
>Category:       bin
>Synopsis:       authunix_create_default includes egid twice
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 12 08:00:00 PDT 1999
>Closed-Date:    
>Last-Modified:  Tue Oct 29 03:51:23 PST 2002
>Originator:     David Mazieres
>Release:        FreeBSD 3.0-RELEASE i386
>Organization:
>Environment:
>Description:

authunix_create_default includes the effictive group ID in the
grouplist (as well as the gid field).  This is inconsistent with
almost all other operating systems, and also inconsistent with the
FreeBSD kernel.

For instance, in nfs_subs.c, the kernel avoids putting
cr->cr_groups[0] in the grouplist, because it has already placed
it in the gid field of the marshalled authunix structure.

   714                  for (i = 1; i <= grpsiz; i++)
   715                          *tl++ = txdr_unsigned(cr->cr_groups[i]);

>How-To-Repeat:
>Fix:
	
The fix is to change authunix_create_default to compensate for the
fact that FreeBSD keeps the effective group ID in the first element
of a processes grouplist (unlike the operating systems for which the
code was originally written).  A simple patch is appended.

Alternatively, you could change the kernel to behave like
authunix_create_default.

The current behavior of having the kernel and libc generate
different authunix structures is quite annoying.  (In particular,
it makes it virtually impossible to "autoconf" RPC behavior in
supposedly portable software).

--- /usr/src/lib/libc/rpc/auth_unix.c	Wed May 28 01:05:02 1997
+++ auth_unix.c	Thu Aug 12 10:31:50 1999
@@ -206,9 +206,9 @@
 	gid = (int)getegid();
 	if ((len = getgroups(NGROUPS, real_gids)) < 0)
 		abort();
-	if(len > NGRPS) len = NGRPS; /* GW: turn `gid_t's into `int's */
+	if(--len > NGRPS) len = NGRPS; /* GW: turn `gid_t's into `int's */
 	for(i = 0; i < len; i++) {
-		gids[i] = (int)real_gids[i];
+		gids[i] = (int)real_gids[i+1];
 	}
 	return (authunix_create(machname, uid, gid, len, gids));
 }


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: johan 
State-Changed-When: Mon Oct 28 13:29:08 PST 2002 
State-Changed-Why:  
The code in question was removed in rev 1.13 of  
src/lib/libc/rpc/auth_unix.c 

If there is a problem with the new code please 
open a new PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=13108 

From: Johan Karlsson <johan@freebsd.org>
To: Bug followup <bug-followup@freebsd.org>
Cc:  
Subject: Re: bin/13108: authunix_create_default includes egid twice
Date: Tue, 29 Oct 2002 12:43:08 +0100

 Adding this to the audit-trail.
 
 ----- Forwarded message from David Mazieres <dm@scs.cs.nyu.edu> -----
 
 From: David Mazieres <dm@scs.cs.nyu.edu>
 To: johan@FreeBSD.org
 Cc: freebsd-bugs@FreeBSD.org
 Subject: Re: bin/13108: authunix_create_default includes egid twice
 Date: Mon, 28 Oct 2002 17:21:44 -0500 (EST)
 
 > Date: Mon, 28 Oct 2002 13:31:29 -0800 (PST)
 > From: Johan Karlsson <johan@FreeBSD.org>
 > 
 > Synopsis: authunix_create_default includes egid twice
 > 
 > State-Changed-From-To: open->closed
 > State-Changed-By: johan
 > State-Changed-When: Mon Oct 28 13:29:08 PST 2002
 > State-Changed-Why: 
 > 	The code in question was removed in rev 1.13 of 
 > 	src/lib/libc/rpc/auth_unix.c
 > 
 > 	If there is a problem with the new code please
 > 	open a new PR.
 > 
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=13108
 
 The new code seems to have the same problem.  The new version of
 authunix_create_default() is:
 
         if ((len = getgroups(NGRPS, gids)) < 0)
                 abort();
         /* XXX: interface problem; those should all have been unsigned */
         return (authunix_create(machname, (int)uid, (int)gid, len,
             (int *)gids));
 
 I think this code should be:
 
         if ((len = getgroups(NGRPS, gids)) < 1)
                 abort();
         /* XXX: interface problem; those should all have been unsigned */
         return (authunix_create(machname, (int)uid, (int)gid, len-1,
             (int *)gids + 1));
 
 Either that, or you should change nfsm_rpchead in
 nfsclient/nfs_subs.C.
 
 Currently, the fact that authunix_create_default and the kernel create
 different AUTHUNIX credentials is a pain for SFS (a FreeBSD-compatible
 network file system that I work on--see www.fs.net).  I realize that
 my needs are somewhat esoteric.  I certainly don't expect you to put
 in a change just because it is good for SFS.  However, just on simple
 aesthetic grounds, doesn't it make sense for the kernel and libc to be
 consistent with each other?  Can't FreeBSD just decide if the AUTHUNIX
 parms should contain a second copy of the egid in the grouplist, and
 then have both libc and the kernel do the same thing?
 
 Of course, at this point, if you were to change the kernel, it would
 make things even worse for me, because right now there is no way of
 autoconfing FreeBSD's behavior.  I have hard-coded the current kernel
 behavior into SFS if the OS name is FreeBSD.
 
 Thanks,
 David
 
 ----- End forwarded message -----
 
 -- 
 Johan Karlsson		mailto:johan@FreeBSD.org
State-Changed-From-To: closed->open 
State-Changed-By: johan 
State-Changed-When: Tue Oct 29 03:50:44 PST 2002 
State-Changed-Why:  
Apparently this is still a problem. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=13108 
>Unformatted:
