[Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes

[Bug libc/1970] New: getgrnam_r() and groups with more than 1024 bytes

[burnus at gmx dot de]

If I have a group with many entries (`/usr/bin/getent group test |wc -c
` > 1024), getgrnam() duely returns the entry whereas getgrnam_r() has some
troubles.

a) sysconf(_SC_GETGR_R_SIZE_MAX);
returns always 1024, which is not large enough, but as there is ENORANGE, it is
not too bad.
SUSv3: "_SC_GETGR_R_SIZE_MAX  Maximum size of getgrgid_r() and getgrnam_r() data
buffers" and "The maximum size needed for this buffer [3rd argument of
getgrnam_r] can be determined with the {_SC_GETGR_R_SIZE_MAX} sysconf() parameter."


b) Using  getgrnam_r() with a big group and a too small buffer =
_SC_GETGR_R_SIZE_MAX == 1024:
(i) group:  files  (in /etc/nsswitch.conf)
returned value: ERANGE, which is ok
(ii) group:  compat (in /etc/nsswitch.conf)
getgrnam_r crashes with a memory access error.
Expected: ERANGE or e.g. EIO.

c) Using  getgrnam_r() with a buffer bigger than 1024
(i) entry < 1024: Ok
(ii) entry > 1024 (independent of group:files vs. group:compat)
Memory access error

-- 
           Summary: getgrnam_r() and groups with more than 1024 bytes
           Product: glibc
           Version: 2.3.5
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: burnus at gmx dot de
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: Compiled on a Linux 2.6.12 system on 2005-09-09.
  GCC host triplet: SUSE Linux 10.0 (i386) with kernel 2.6.14-
                    20051028140608-default
GCC target triplet: Configured for i686-suse-linux.


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes

[kukuk at suse dot de]

------- Additional Comments From kukuk at suse dot de  2005-12-09 07:11 -------
(In reply to comment #0)
> If I have a group with many entries (`/usr/bin/getent group test |wc -c
> ` > 1024), getgrnam() duely returns the entry whereas getgrnam_r() has some
> troubles.
> 
> a) sysconf(_SC_GETGR_R_SIZE_MAX);
> returns always 1024, which is not large enough, but as there is ENORANGE, it is
> not too bad.
> SUSv3: "_SC_GETGR_R_SIZE_MAX  Maximum size of getgrgid_r() and getgrnam_r() data
> buffers" and "The maximum size needed for this buffer [3rd argument of
> getgrnam_r] can be determined with the {_SC_GETGR_R_SIZE_MAX} sysconf()
parameter."
> 
> 
> b) Using  getgrnam_r() with a big group and a too small buffer =
> _SC_GETGR_R_SIZE_MAX == 1024:
> (i) group:  files  (in /etc/nsswitch.conf)
> returned value: ERANGE, which is ok
> (ii) group:  compat (in /etc/nsswitch.conf)
> getgrnam_r crashes with a memory access error.
> Expected: ERANGE or e.g. EIO.
> 
> c) Using  getgrnam_r() with a buffer bigger than 1024
> (i) entry < 1024: Ok
> (ii) entry > 1024 (independent of group:files vs. group:compat)
> Memory access error


As I told you already in Novell bugzilla: Your testprogram works fine and does
not crash for me:
_SC_GETGR_R_SIZE_MAX = 2048
mygetgrnam("testg", 1024) returned: ERANGE

DONE


So please explain exactly how to reproduce and deliver a backtrace.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kukuk at suse dot de


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes

[burnus at gmx dot de]

------- Additional Comments From burnus at gmx dot de  2005-12-09 11:53 -------
> _SC_GETGR_R_SIZE_MAX = 2048
> mygetgrnam("testg", 1024) returned: ERANGE

Hmm, _SC_GETGR_R_SIZE_MAX = 2048 is interesting. What do you have in
/etc/nsswitch.conf? I get the crash only with compat, with file I also get ERANGE.

(gdb) run test
Starting program: /tmp/getent_test test
_SC_GETGR_R_SIZE_MAX = 1024
[... working getgrnam_r ...]
Call getgrnam_r(name = "test", grp, buffer, bufsize=1024,result)

Program received signal SIGSEGV, Segmentation fault.
0x401a7c10 in memchr () from /lib/tls/libc.so.6
(gdb) bt
#0  0x401a7c10 in memchr () from /lib/tls/libc.so.6
#1  0x00000000 in ?? ()
#2  0x000003ff in ?? ()
#3  0x401931dd in _IO_getline_info_internal () from /lib/tls/libc.so.6
#4  0x4019314f in _IO_getline_internal () from /lib/tls/libc.so.6
#5  0x4019b11a in fgets_unlocked () from /lib/tls/libc.so.6
#6  0x40019f2f in _nss_compat_getgrnam_r () from /lib/libnss_compat.so.2
#7  0x401c7354 in getgrnam_r@@GLIBC_2.1.2 () from /lib/tls/libc.so.6
#8  0x08048888 in mygetgrnam_r (name=0xbfa590aa "test", bufsize=1024) at
getent_test.cpp:36
#9  0x08048a8c in main (argc=2, argv=0xbfa58e04) at getent_test.cpp:86

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes

[burnus at gmx dot de]

------- Additional Comments From burnus at gmx dot de  2005-12-09 12:00 -------
> [... working getgrnam_r ...]
(This of cause means working getgrnam(); this never failed for me.)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes

[kukuk at suse dot de]

------- Additional Comments From kukuk at suse dot de  2005-12-09 12:01 -------
(In reply to comment #2)
> > _SC_GETGR_R_SIZE_MAX = 2048
> > mygetgrnam("testg", 1024) returned: ERANGE
> 
> Hmm, _SC_GETGR_R_SIZE_MAX = 2048 is interesting. 

It's because your test program you submitted contains "2*"

> I get the crash only with compat, with file I also get ERANGE.

So why did you wrote something complete different in the initial comment?
"(independent of group:files vs. group:compat)".
What is now the truth?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes

[burnus at gmx dot de]

------- Additional Comments From burnus at gmx dot de  2005-12-09 12:27 -------
Created an attachment (id=789)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=789&action=view)
Test program, compile with g++ (uses "new")

I thought I attached the program here, but seemingly I didn't -- doing so now.

> > I get the crash only with compat, with file I also get ERANGE.
> So why did you wrote something complete different in the initial comment?
> "(independent of group:files vs. group:compat)".

Well, both is true:

Using	 getgrnam_r(name = "test", grp, buffer, bufsize=1024,result)
it only crashes with "group: compat". (Otherwise I get a ERANGE)

But using a buffer > 1024 it crashes with both group:compat and group:files
(stopping the nscd makes sense, otherwise the results can come from the cache,
I believe)

(gdb) run test
Starting program: /tmp/getent_test2 test
_SC_GETGR_R_SIZE_MAX = 1024

Call getgrnam_r(name = "test", grp, buffer, bufsize=2048,result)

Program received signal SIGSEGV, Segmentation fault.
0x4000b46a in fixup () from /lib/ld-linux.so.2
(gdb) bt
#0  0x4000b46a in fixup () from /lib/ld-linux.so.2
#1  0x4000b2c0 in _dl_runtime_resolve () from /lib/ld-linux.so.2
#2  0x4001cd54 in internal_endent () from /lib/libnss_files.so.2
#3  0x4001d0a2 in _nss_files_getgrnam_r () from /lib/libnss_files.so.2
#4  0x401c7354 in getgrnam_r@@GLIBC_2.1.2 () from /lib/tls/libc.so.6
#5  0x080485b4 in mygetgrnam_r (name=0xbfa390a9 "test", bufsize=2048) at
getent_test2.cpp:15
#6  0x08048628 in main (argc=2, argv=0xbfa376e4) at getent_test2.cpp:23


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes

[drepper at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   GCC host triplet|SUSE Linux 10.0 (i386) with |i386-linux
                   |kernel 2.6.14-              |
                   |20051028140608-default      |


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/1970] getgrnam_r() and groups with more than 1024 bytes

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2006-04-23 19:47 -------
There are at least two bugs in the program which have to make it crash:

- the test whether getgrnam_r returns something must be

  if(result == NULL && res == 0) {

  and not

  if(&result == NULL && res == 0) {

  &result is always != NULL


- you cannot call delete on 'result'.  Only on 'buffer'.


I'm closing this bug.  Reopen only after you can demonstrate with a C program
that there is indeed a problem.  In this case you also have to provide a
description of the setup.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=1970

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.