From roottcsh@alano.diatel.upm.es  Thu Mar 16 09:19:06 1995
Received: from alano.diatel.upm.es ([138.100.49.9]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id JAA13317 for <FreeBSD-gnats-submit@freebsd.org>; Thu, 16 Mar 1995 09:18:06 -0800
Received: (from root@localhost) by alano.diatel.upm.es (8.6.9/8.6.9) id SAA01786; Thu, 16 Mar 1995 18:13:37 +0100
Message-Id: <199503161713.SAA01786@alano.diatel.upm.es>
Date: Thu, 16 Mar 1995 18:13:37 +0100
From: roottcsh@alano.diatel.upm.es
Reply-To: jmrueda@diatel.upm.es
To: FreeBSD-gnats-submit@freebsd.org
Subject: reading groups from YP causes core dumps in a client machine
X-Send-Pr-Version: 3.2

>Number:         244
>Category:       misc
>Synopsis:       reading groups from YP causes core dumps in a client machine
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs (FreeBSD bugs mailing list)
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 16 09:20:00 1995
>Closed-Date:    Fri Mar 17 21:06:37 PST 1995
>Last-Modified:
>Originator:     Operator
>Release:        FreeBSD 2.0-RELEASE i386
>Organization:
>Environment:
YP/NIS is served by a machine running SunOS 4.1.1.
DES encryption is installed in the FreeBSD machine (from skeleton.mikom.csir.co.za).
	

>Description:
If you enable group sharing under YP (that is, you add the special "+" group
entry to /etc/group), any process that attempts to get the
list of group ids of a user, dies with a core dump.

Note: enabling YP for user ids seems to work fine.
	

>How-To-Repeat:
After starting NIS (make /var/yp ; ypbind), append the following to /etc/group:
+:::

Now, attempt to login. It will core dump when starting up your session.
Or execute "id someone". It will core dump.
Or wait until cron executes atrun. atrun will core dump.
	

>Fix:
Not known.

The only thing I've done is get a stack dump of a process that dies because of
this:

The command executed is "id jmrueda". gdb reports:

Program received signal SIGSEGV (11), Segmentation fault
0x8055870 in strtol.so ()
(gdb) bt
#0  0x8055870 in strtol.so ()
#1  0x80500cc in atoi.so ()
#2  0x802f712 in _gr_breakout_yp ()
#3  0x802f975 in _nextypgroup ()
#4  0x802f208 in getgrent ()
#5  0x802f9e5 in getgrouplist.so ()
#6  0x1daa in user (pw=0x807803c) at id.c:242
#7  0x18fb in main (argc=1, argv=0xefbfde0c) at id.c:142
	

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: wpaul 
State-Changed-When: Fri Mar 17 21:06:37 PST 1995 
State-Changed-Why:  
Fixed. the grscan() utility function inside getgrent.c in libc would 
slam head-first into a null pointer dereference when it hit the +::: 
entry while processing a string of getgrent() calls. This means that 
any programs that tried to scroll through the group database with 
getgrent() would self-destruct after retrieving the last locally 
stored group entry. grscan() is now smart enough to avoid the circumstances 
that would lead to the null pointer dereference. 
>Unformatted:



:
