Your message dated Mon, 28 Feb 2005 09:40:44 +0900 with message-id <[EMAIL PROTECTED]> and subject line Bug#296490: libc6: getgrnam segfault (using __nscd_getgrnam_r) has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 22 Feb 2005 18:52:31 +0000 >From [EMAIL PROTECTED] Tue Feb 22 10:52:31 2005 Return-path: <[EMAIL PROTECTED]> Received: from master.debian.org [146.82.138.7] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1D3f94-0008Qx-00; Tue, 22 Feb 2005 10:52:30 -0800 Received: from x108040.its-m.tudelft.nl (localhost.localdomain) [145.94.108.40] by master.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1D3f94-0004ut-00; Tue, 22 Feb 2005 12:52:30 -0600 Content-Type: multipart/mixed; boundary="===============1922799435==" MIME-Version: 1.0 From: Tom Parker <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: libc6: getgrnam segfault (using __nscd_getgrnam_r) X-Mailer: reportbug 3.8 Date: Tue, 22 Feb 2005 19:52:28 +0100 X-Debbugs-Cc: [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-9.0 required=4.0 tests=BAYES_00,HAS_PACKAGE, OUR_MTA_MSGID,X_DEBBUGS_CC autolearn=ham version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: This is a multi-part MIME message sent by reportbug. --===============1922799435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Package: libc6 Version: 2.3.2.ds1-20 Severity: normal Tags: patch Calling getgrnam() with a NULL argument, with group in /etc/nsswitch.conf set to 'compat' can cause a segfault in __nscd_getgrnam_r due to a lack of a check for a NULL string before doing strlen(). I've attached a patch, but this is untested due to the amount of time (+amount of percieved risk) of replacing libc6 with a self-modified version. However, it's a two-line fix, so *should* be ok. -- System Information: Debian Release: 3.0 APT prefers testing APT policy: (103, 'testing'), (102, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7 The Berkeley database routines [gl -- no debconf information --===============1922799435== Content-Type: text/x-c; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="__nscd_getgrnam_r.patch" --- nscd/nscd_getgr_r.c Tue Feb 22 19:45:06 2005 +++ nscd/nscd_getgr_r.c.fixed Tue Feb 22 19:44:33 2005 @@ -42,6 +42,8 @@ __nscd_getgrnam_r (const char *name, struct group *resultbuf, char *buffer, size_t buflen) { + if (name == NULL) + return NULL; return nscd_getgr_r (name, strlen (name) + 1, GETGRBYNAME, resultbuf, buffer, buflen); } --===============1922799435==-- --------------------------------------- Received: (at 296490-done) by bugs.debian.org; 28 Feb 2005 00:40:45 +0000 >From [EMAIL PROTECTED] Sun Feb 27 16:40:45 2005 Return-path: <[EMAIL PROTECTED]> Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [218.44.239.78] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1D5Yxp-0004On-00; Sun, 27 Feb 2005 16:40:45 -0800 Received: from omega.webmasters.gr.jp (localhost [127.0.0.1]) by webmasters.gr.jp (Postfix) with ESMTP id 8A151DEB1B; Mon, 28 Feb 2005 09:40:44 +0900 (JST) Date: Mon, 28 Feb 2005 09:40:44 +0900 Message-ID: <[EMAIL PROTECTED]> From: GOTO Masanori <[EMAIL PROTECTED]> To: Daniel Jacobowitz <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Cc: Tom Parker <[EMAIL PROTECTED]>, Florian Weimer <[EMAIL PROTECTED]> Subject: Re: Bug#296490: libc6: getgrnam segfault (using __nscd_getgrnam_r) In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> User-Agent: Wanderlust/2.9.9 (Unchained Melody) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (i386-debian-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: At Wed, 23 Feb 2005 21:58:25 -0500, Daniel Jacobowitz wrote: > > Florian Weimer wrote: > > >* Tom Parker: > > >>Calling getgrnam() with a NULL argument, with group in > > >>/etc/nsswitch.conf set to 'compat' can cause a segfault in > > >>__nscd_getgrnam_r due to a lack of a check for a NULL string before > > >>doing strlen(). > > > > > >Is there any standard that defines the behavior of getgrnam(NULL)? > > > > The man page GETGRNAM(3) says: > > > > RETURN VALUE > > The getgrnam() and getgrgid() functions return a pointer to the > > group information structure, or NULL if the matching entry is not found > > or an error occurs. If an error occurs, errno is set appropriately. If > > one wants to check errno after the call, it should be set to zero before > > the call. > > > > I've had a quick look at the POSIX (1003.1-2004) specs, and they say > > approximately the same thing (see > > http://www.opengroup.org/onlinepubs/000095399/functions/getgrnam.html). > > There isn't an exact thing for what to do in the case of getgrnam(NULL), > > but given that the "matching entry is not found" (because there can't be > > a NULL group), then I think that returning NULL is the correct behaviour. > > No, it's not at all the same thing. None of the library functions are > required to be robust against NULL input; there's no point making an > exception for getgrnam without making an exception for, say, strlen. I agree with the Daniel's opinion. I close this bug. Tom, if you think another rock reason, please let us know. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]