Date: Mon, 26 Jun 1995 07:59:50 -0700 From: Bill Paul <wpaul> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/gen getgrent.c Message-ID: <199506261459.HAA16244@freefall.cdrom.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506261459.HAA16244>