[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#325465: marked as done (Difference between sysconf(_SC_NGROUPS_MAX) and /proc/sys/kernel/ngroups_max)

Your message dated Wed, 31 Aug 2005 13:31:32 +0900
with message-id <81ll2iviaj.wl%gotom@debian.or.jp>
and subject line Bug#325465: Difference between sysconf(_SC_NGROUPS_MAX) and /proc/sys/kernel/ngroups_max
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; 28 Aug 2005 20:46:09 +0000
>From beuc@gnu.org Sun Aug 28 13:46:09 2005
Return-path: <beuc@gnu.org>
Received: from 26.mail-out.ovh.net [] 
	by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
	id 1E9U2b-0004VT-00; Sun, 28 Aug 2005 13:46:09 -0700
Received: (qmail 17490 invoked by uid 503); 28 Aug 2005 20:46:28 -0000
Received: (QMFILT: 1.0); 28 Aug 2005 20:46:28 -0000
Received: from b6.ovh.net (HELO mail29.ha.ovh.net) (
  by 26.mail-out.ovh.net with DES-CBC3-SHA encrypted SMTP; 28 Aug 2005 20:46:28 -0000
Received: from b0.ovh.net (HELO queue-out) (
	by b0.ovh.net with SMTP; 28 Aug 2005 20:46:09 -0000
Received: from mail156.ha.ovh.net (
  by mail29.ha.ovh.net with SMTP; 28 Aug 2005 20:46:08 -0000
Received: from b0.ovh.net (HELO queue-pre) (
	by b0.ovh.net with SMTP; 28 Aug 2005 20:46:07 -0000
Received: from stbarthelemy-6-82-230-99-124.fbx.proxad.net (HELO localhost.localdomain) (
  by ns0.ovh.net with SMTP; 28 Aug 2005 20:46:07 -0000
Received: from me by localhost.localdomain with local (Exim 4.52)
	id 1E9U2Z-0001Ib-Ri; Sun, 28 Aug 2005 22:46:07 +0200
Date: Sun, 28 Aug 2005 22:46:07 +0200
From: Sylvain Beucler <beuc@gnu.org>
To: submit@bugs.debian.org
Cc: savannah-hackers-public@gnu.org
Subject: Difference between sysconf(_SC_NGROUPS_MAX) and /proc/sys/kernel/ngroups_max
Message-ID: <[🔎] 20050828204607.GB4920@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Operating-System: GNU/Linux
User-Agent: Mutt/1.5.9i
X-Ovh-Remote: (stbarthelemy-6-82-230-99-124.fbx.proxad.net)
X-Ovh-Local: (ns0.ovh.net)
X-Spam-Check: fait|type 1&3|0.0|H 0.5
Delivered-To: submit@bugs.debian.org
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=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
	autolearn=no version=2.60-bugs.debian.org_2005_01_02

Package: glibc
Version: 2.3.2.ds1-22
Severity: important

There is a difference between sysconf(_SC_NGROUPS_MAX) and

#include <stdio.h>
#include <unistd.h>

int main(void) {
  printf("%d\n", sysconf(_SC_NGROUPS_MAX));
  return 0;
=3D> 32

$ cat /proc/sys/kernel/ngroups_max
=3D> 65536

This applies under stable and testing, unstable works properly :)

More details: I sent this bug report to the shadow/passwd people, but
they think the problem comes from the difference above.

We would really need to get more groups per users in our stable

The stable kernel has a limit of 65536 groups per users:
$ cat /proc/sys/kernel/ngroups_max

However usermod is still limited to 32 users:
$ usermod -G testgroup1,testgroup2,testgroup3,testgroup4,testgroup5,testgro=
p100 test
usermod: too many groups specified (max 32).

Incidentally 'id' is also limited to 32
users. sysconf(_SC_NGROUPS_MAX) also returns 32.

stable's /usr/include/linux/limits.h has NGROUPS_MAX set to 32. In
testing and unstable it is set to 65536.

The usermod limitation happens in stable and testing (tested with
their respective default kernel), but not in unstable (tested with the
testing kernel - all tested kernels having ngroups_max=3D65536).

Basically we have a kernel without the limitation, but the executables
have the limitation, which was probably set at compile time.

Do you know what's the origin of the limitation, and how it could be
fixed to match the default kernel's?

GNU Savannah: http://savannah.gnu.org

Received: (at 325465-done) by bugs.debian.org; 31 Aug 2005 04:31:34 +0000
>From gotom@debian.or.jp Tue Aug 30 21:31:34 2005
Return-path: <gotom@debian.or.jp>
Received: from omega.webmasters.gr.jp (webmasters.gr.jp) [] 
	by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
	id 1EAKG5-00088H-00; Tue, 30 Aug 2005 21:31:33 -0700
Received: from omega.webmasters.gr.jp (localhost [])
	by webmasters.gr.jp (Postfix) with ESMTP id F1520DEB1B;
	Wed, 31 Aug 2005 13:31:32 +0900 (JST)
Date: Wed, 31 Aug 2005 13:31:32 +0900
Message-ID: <81ll2iviaj.wl%gotom@debian.or.jp>
From: GOTO Masanori <gotom@debian.or.jp>
To: Sylvain Beucler <beuc@gnu.org>, 325465-done@bugs.debian.org
Cc: Thiemo Seufer <ths@networkno.de>, savannah-hackers-public@gnu.org
Subject: Re: Bug#325465: Difference between sysconf(_SC_NGROUPS_MAX) and /proc/sys/kernel/ngroups_max
In-Reply-To: <[🔎] 20050829180929.GA6071@localhost.localdomain>
References: <[🔎] 20050828204607.GB4920@localhost.localdomain>
	<[🔎] 20050828215445.GF21717@hattusa.textio>
	<[🔎] 20050829180929.GA6071@localhost.localdomain>
User-Agent: Wanderlust/2.11.30 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Delivered-To: 325465-done@bugs.debian.org
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

Version: 2.3.5-3

At Mon, 29 Aug 2005 20:09:29 +0200,
Sylvain Beucler wrote:
> As far as I understand, sysconf() should get the information at run
> time. How comes that he returns 32 on a system that support 65536?

At least with 2.3.5-6 in unstable, the problem should be fixed - it
looks /proc/sys/kernel/ngroups_max.

-- gotom

Reply to: