Bug 10573
Summary: | getgrgid(3) with gid=nobody fails (not matching manpage / passing back correct errno) | ||
---|---|---|---|
Product: | Other | Reporter: | Garrett Cooper (yaneurabeya) |
Component: | Other | Assignee: | Michael Kerrisk (mtk.manpages) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | bunk, mtk.manpages |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.9-42.7.ELsmp x86_64, 2.6.23.17 i686, 2.6.24.3 x86_64 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
Test C-file for getgrguid(3).
Wrapper script for C-test file. |
Description
Garrett Cooper
2008-04-28 12:38:04 UTC
Created attachment 15960 [details]
Test C-file for getgrguid(3).
Created attachment 15961 [details]
Wrapper script for C-test file.
Test cases with i=42 and i=99 *should* fail (well, they did on my system ;)..) unless /etc/group has those GID entries.
The documentation (provided by debian?) available in Gentoo is also out of date and doesn't reflect this change in the code between 2.6.9 and 2.6.24. Michael, can you look at this bug? Garrett, I'm having a little trouble understanding your bug report. The problem is, I don't see a simple statement of what you get, and what you expect. > It appears that there was a bug with the values returned by > getgrgid(3) between kernel version 2.6.9 and 2.6.23. getgrgid(3) is not a kernel interface. It's a glibc interface. What version of glibc are you using? > The first issues is the fact that particular kernel versions > (2.6.9 in this example) were looking up rguid's incorrectly. Can you p;ease explain this. Which part of the kernel (i.e., what suystem call) is looking up rguids incorrectly? What do you mean by "incorrect"? > The second issue is the fact that contemporary kernel versions > do not set an appropriate errno value when an error occurs. Not > being able to find a user entry should not return SUCCESS(errno=0). Does the following glibc bug report have relevance here? http://sources.redhat.com/bugzilla/show_bug.cgi?id=3195 In the comments of your C program you write: * It's been proven that this test fails on some kernel versions * (2.6.9 with RHEL-5 for instance), in particular when * getgrguid(3) != getgeguid(3). But there is no such API as getgeguid(). You're right. getgeguid doesn't exist. I was thinking (r = real, e = executing). I think it's 2.3.5, but I don't have root access on the Redhat machine so I can't tell via rpm or yum. The RHEL version is RHEL-5 I think (RHEL-4, Nahant update 4), correct? (In reply to comment #6) > You're right. getgeguid doesn't exist. I was thinking (r = real, e = > executing). > I think it's 2.3.5, What is "it"? glibc? You left many of my other questions unanswered, which makes it hard to provide further input... > but I don't have root access on the Redhat machine so I > can't tell via rpm or yum. If you are trying to determine the glibc version, then just execute the libc file, something like: $( ldd /bin/ls | grep libc.so ) > The RHEL version is RHEL-5 I think (RHEL-4, Nahant update 4), correct? I don't know what you are referring to here. Regardless of the comments, the bug appears to be invalid from a kernel end since the issue appears to be with whatever library / access method is used to look up the user entry... the issue is no doubt from ncsd, or some other associated means. I say this because if you spot the actual "glibc" function reference, it's an extern to another library (just do "grep 'getgrgid(' /usr/include/grp.h". ldd only reveals the libc.so revision (which is .6, but many versions of libc.so in the 2.3.x ~ 2.5.x series are .6 I think). (In reply to comment #8) > ldd only reveals the libc.so revision (which is .6, but many versions of > libc.so in the 2.3.x ~ 2.5.x series are .6 I think). Hmmm -- I missed a piece in my commands: $( ldd /bin/ls | grep libc.so | awk '{ print $3}') Note that the initial $ is *not* the shell prompt -- it's part of "$(" |