From owner-freebsd-commit  Mon Jun 26 08:00:25 1995
Return-Path: commit-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id IAA16278
          for commit-outgoing; Mon, 26 Jun 1995 08:00:25 -0700
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id IAA16258
          for cvs-lib-outgoing; Mon, 26 Jun 1995 08:00:01 -0700
Received: (from wpaul@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id HAA16244
          ; Mon, 26 Jun 1995 07:59:50 -0700
Date: Mon, 26 Jun 1995 07:59:50 -0700
From: Bill Paul <wpaul>
Message-Id: <199506261459.HAA16244@freefall.cdrom.com>
To: CVS-commiters, cvs-lib
Subject: cvs commit: src/lib/libc/gen getgrent.c
Sender: commit-owner@FreeBSD.org
Precedence: bulk

wpaul       95/06/26 07:59:49

  Modified:    lib/libc/gen  getgrent.c
  Log:
  Fix for a potential problem reported by a user I bumped into on IRC
  last night:
  
  _gr_breakout_yp() doesn't check for badly formatted NIS group entries.
  For example, a bogus entry like this:
  
  bootp::user1,user2,user3
  
  will lead to a null pointer dereference and a SEGV (note that the GID
  field is missing -- this results in one of the strsep(&result, ":")
  returning NULL). The symtpom of this problem is programs dumping
  core left and right the moment you add a + entry to /etc/group.
  Note that while this is similar to an earlier bug, it's caused by a
  different set of circumstances.
  
  The fix is to check for the NULL pointers and have _gr_breakout_yp()
  punt and return a failure code if it catches one. This is more or
  less the behavior of SunOS: if a bad NIS group entry is encountered,
  it's silently ignored. I don't think our standard (non-NIS) group
  parsing code behaves the same way. It doesn't crash though, so I'm
  citing the 'it ain't broken, don't fix it' rule and leaving it alone.
  
  I'll probably have to add similar checks to _pw_breakout_yp() in
  getpwent.c to ward off the same problems. It's rare that bad NIS
  map entries like this occur, but we should handle them gracefully
  when they do.