NetBSD Problem Report #47293

From Wolfgang.Stukenbrock@nagler-company.com  Fri Dec  7 13:01:17 2012
Return-Path: <Wolfgang.Stukenbrock@nagler-company.com>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id A998563E814
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  7 Dec 2012 13:01:17 +0000 (UTC)
Message-Id: <20121207130107.C3F47123B8D@test-s0.nagler-company.com>
Date: Fri,  7 Dec 2012 14:01:07 +0100 (CET)
From: Wolfgang.Stukenbrock@nagler-company.com
Reply-To: Wolfgang.Stukenbrock@nagler-company.com
To: gnats-bugs@gnats.NetBSD.org
Subject: innetgr(3) failed to match correctly
X-Send-Pr-Version: 3.95

>Number:         47293
>Category:       lib
>Synopsis:       innetgr(3) failed to match correctly
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Dec 07 13:05:00 +0000 2012
>Last-Modified:  Fri Dec 07 14:30:05 +0000 2012
>Originator:     Dr. Wolfgang Stukenbrock
>Release:        NetBSD 5.1.2
>Organization:
Dr. Nagler & Company GmbH
>Environment:


System: NetBSD test-s0 5.1.2 NetBSD 5.1.2 (NSW-WS) #1: Thu Dec 6 12:56:04 CET 2012 wgstuken@test-s0:/usr/src/sys/arch/amd64/compile/NSW-WS amd64
Architecture: x86_64
Machine: amd64
>Description:
	The behaviour of the NetBSD innetgr() differs from the "reference" Version of Sun in the following way.
	If there is a netgroup entry link '(hhh,blub,XXX)' in a netgroup, it is possible to match it
	on Sun with specifying all three paramters like innetgr(<nt>, "hhh", "blub", "XXX"), but it is
	impossible to match the entry in the netbsd Version.
	The problem is due to a "bad" speed optimization exit in the netbsd version.
	In file /usr/src/lib/libc/gen/getnetgrent.c in function _local_innetgr() there is a "fast" check
	against netgroup.byuser of netgroup.byhost, if only on of them is set.
	But accedently the function is exited if a domain is specified.
	This will fail all kind of lookups where all three parts are specified.
	It will also fail to match an empty domain part in the netgroup, if some data is passed to innetgr().
>How-To-Repeat:
	Create a netgroup with all fiels filled in and try to match an entry
	with all three fields specified in innetgr() call.
	It will never match.
>Fix:
	The following patch will fix the problem and produces the expected matches as on Solaris.

--- getnetgrent.c.orig  2012-12-07 13:53:52.000000000 +0100
+++ getnetgrent.c       2012-12-07 13:55:42.000000000 +0100
@@ -795,16 +795,21 @@
                        *retval = 1;
                        return NS_SUCCESS;
                }
+               /* If a domainname is given, we would have found a match */
+               if (domain != NULL) {
+                       *retval = 0;
+                       return NS_SUCCESS;
+               }
        } else if (host == NULL && user != NULL) {
                if (in_lookup(grp, user, domain, _NG_KEYBYUSER)) {
                        *retval = 1;
                        return NS_SUCCESS;
                }
-       }
-       /* If a domainname is given, we would have found a match */
-       if (domain != NULL) {
-               *retval = 0;
-               return NS_SUCCESS;
+               /* If a domainname is given, we would have found a match */
+               if (domain != NULL) {
+                       *retval = 0;
+                       return NS

>Audit-Trail:
From: Wolfgang Stukenbrock <wolfgang.stukenbrock@nagler-company.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/47293: innetgr(3) failed to match correctly
Date: Fri, 07 Dec 2012 15:28:49 +0100

 Hi again,

 even with the patch send before, there is still a differens in matching 
 against the Solaris version.

 Again the short-Cur ist the source of the problem ....

 If there is an entry (-,blub,) in the netgroup on Solaris
 innetgr(<ngr>, NULL, "blub", "xxx") will match but the NetBSD version
 will not match.
 The problem is, that in this case we have checked for "blub.xxx" in 
 netgroup.byuser but the relevant entry there is "blub.*".
 So we also need to check for an entry without domainname, even if we got 
 a domainname.

 This modified patch will solve this problem too:

 diff -u -r1.1 getnetgrent.c
 --- getnetgrent.c       2012/12/07 13:02:55     1.1
 +++ getnetgrent.c       2012/12/07 14:26:16
 @@ -795,16 +795,29 @@
                          *retval = 1;
                          return NS_SUCCESS;
                  }
 +               /* If a domainname is given, we would have found a match  */
 +               if (domain != NULL) {
 +                       if (in_lookup(grp, host, NULL, _NG_KEYBYHOST)) {
 +                               *retval = 1;
 +                               return NS_SUCCESS;
 +                       }
 +                       *retval = 0;
 +                       return NS_SUCCESS;
 +               }
          } else if (host == NULL && user != NULL) {
                  if (in_lookup(grp, user, domain, _NG_KEYBYUSER)) {
                          *retval = 1;
                          return NS_SUCCESS;
                  }
 -       }
 -       /* If a domainname is given, we would have found a match */
 -       if (domain != NULL) {
 -               *retval = 0;
 -               return NS_SUCCESS;
 +               /* If a domainname is given, we would have found a match */
 +               if (domain != NULL) {
 +                       if (in_lookup(grp, user, NULL, _NG_KEYBYUSER)) {
 +                               *retval = 1;
 +                               return NS_SUCCESS;
 +                       }
 +                       *retval = 0;
 +                       return NS_SUCCESS;
 +               }
          }

          /* Too bad need the slow recursive way */


 gnats-admin@NetBSD.org wrote:

 > Thank you very much for your problem report.
 > It has the internal identification `lib/47293'.
 > The individual assigned to look at your
 > report is: lib-bug-people. 
 > 
 > 
 >>Category:       lib
 >>Responsible:    lib-bug-people
 >>Synopsis:       innetgr(3) failed to match correctly
 >>Arrival-Date:   Fri Dec 07 13:05:00 +0000 2012
 >>


>Unformatted:

Home	PR Database Search