Bug #3683: getgrnam on computer with NIS group (+)?

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: 1.9.3
• ruby -v: trunk

[rocky (Rocky Bernstein)]

=begin
When I ran "make check" on a computer that has NIS groups, I notice that the ruby-test/test/etc/test_etc.rb fails with this:

1. Error:
   test_getgrnam(TestEtc):
   ArgumentError: can't find group for +
   /src/external-vcs/ruby-test/test/etc/test_etc.rb:86:in getgrnam' /src/external-vcs/ruby-test/test/etc/test_etc.rb:86:in block in test_getgrnam'
   /src/external-vcs/ruby-test/test/etc/test_etc.rb:85:in each_value' /src/external-vcs/ruby-test/test/etc/test_etc.rb:85:in test_getgrnam'

I guess this is because "+" isn't understood as a NIS group. I'm not sure what you want to do about this, but I thought I'd report it.

At "remedy" might not test when the group name is "+" at the end of the /etc/group file. Or one might want to change to code to handle this situation.
=end

[naruse (Yui NARUSE)]

=begin
show ruby -v.
=end

[rocky (Rocky Bernstein)]

=begin
$ ruby -v
ruby 1.9.3dev (2010-07-15 trunk 28647) [i686-linux]

Sorry for the omission.
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Feedback

=begin
Can you tell us which environment that happen?
=end

[phasis68 (Heesob Park)]

=begin
Refer to
http://ha.redhat.com/mirrors/LDP/LDP/nag2/x-087-2-nis.passwd.html
http://docs.hp.com/en/B9106-90011/group.4.html

=end

[shyouhei (Shyouhei Urabe)]

=begin
No no, I mean, current Etc.group { ... } is a very thin wrapper to call getgrent(3) over and over. We do not even open the /etc/group file for us directly. All accesses to those info are via libc calls. So if you encounter that exception, it's not us but your libc who should understand your '+' entry. Hence my previous question.
=end

[rocky (Rocky Bernstein)]

=begin
I'm in Tokyo right now, and can't get access to the computer where this was happening. Also, I am not able to make the test fail on my laptop. So hopefully I will be able give useful information when I get back to the U.S with useful information which should be no earlier than Sept 8.
=end

[rocky (Rocky Bernstein)]

=begin
I ran the following program to show group information in C on the computer where the test was failing:

#include <sys/types.h>
#include <grp.h>
#include <stdio.h>
#include <errno.h>
int main(int argc, const char *argv[])
{
struct group *grp;
errno = 0;
while (grp = getgrent()) {
printf("name: %s, passwd: %s, errno %d\n", grp->gr_name, grp->gr_passwd, errno);
errno = 0;
}
}

The output shows:

name: root, passwd: x, errno 0
...
name: snmp, passwd: x, errno 0
name: +, passwd: , errno 0

My /etc/group file

root:x:0:
...
snmp:x:139:
+:::

So getgrent() reports "+" as a group name; "+" is at the end of the /etc/group file. However it isn't the name of a group. Instead, "+" indicates including NIS groups. See for example section 3. http://lyre.mit.edu/~powell/debian-howto/nis.html

So getgrnam() returns 0 and errno shows no indication of an error (that is, errno is 0).

=end

[nobu (Nobuyoshi Nakada)]

=begin
Hi,

At Wed, 8 Sep 2010 00:47:09 +0900,
Rocky Bernstein wrote in [ruby-core:32106]:

So getgrent() reports "+" as a group name; "+" is at the end
of the /etc/group file. However it isn't the name of a
group. Instead, "+" indicates including NIS groups. See for
example section
3. http://lyre.mit.edu/~powell/debian-howto/nis.html

Then it's the issue of your libc. Why don't you reveal which
distro you are using?

--
Nobu Nakada

=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Feedback to Third Party's Issue

=begin

=end

[rocky (Rocky Bernstein)]

=begin
Sorry for the omission. Ubuntu Lucid. Details follow. If there is more information you'd like let me know.

$ lsb_release -a
LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch:core-4.0-ia32:core-4.0-noarch:cxx-3.0-ia32:cxx-3.0-noarch:cxx-3.1-ia32:cxx-3.1-noarch:cxx-3.2-ia32:cxx-3.2-noarch:cxx-4.0-ia32:cxx-4.0-noarch:desktop-3.1-ia32:desktop-3.1-noarch:desktop-3.2-ia32:desktop-3.2-noarch:desktop-4.0-ia32:desktop-4.0-noarch:graphics-2.0-ia32:graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:graphics-3.1-ia32:graphics-3.1-noarch:graphics-3.2-ia32:graphics-3.2-noarch:graphics-4.0-ia32:graphics-4.0-noarch:printing-3.2-ia32:printing-3.2-noarch:printing-4.0-ia32:printing-4.0-noarch:qt4-3.1-ia32:qt4-3.1-noarch
Distributor ID: Ubuntu
Description: Ubuntu 10.04.1 LTS
Release: 10.04
Codename: lucid

$ uname -a
Linux verne 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:24:04 UTC 2010 i686 GNU/Linux

$ cat /etc/debian_version
squeeze/sid

$ dpkg -l nis libc-bin libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii libc-bin 2.11.1-0ubuntu Embedded GNU C Library: Binaries
ii libc6 2.11.1-0ubuntu Embedded GNU C Library: Shared libraries
ii nis 3.17-31 clients and daemons for the Network Informat

=end

[nobu (Nobuyoshi Nakada)]

=begin
Hi,

At Wed, 8 Sep 2010 12:41:48 +0900,
Rocky Bernstein wrote in [ruby-core:32118]:

Sorry for the omission. Ubuntu Lucid. Details follow. If there is more
information you'd like let me know.

I can't reproduce it on the x86_64 Ubuntu 10.04.1.

ii nis 3.17-31 clients and daemons for the Network Informat

What does `ypcat group' emit?

--
Nobu Nakada

=end

[nobu (Nobuyoshi Nakada)]

• Status changed from Third Party's Issue to Feedback

=begin

=end

[rocky (Rocky Bernstein)]

=begin
Hi, you reported:

I can't reproduce it on the x86_64 Ubuntu 10.04.1.

I am not not surprised because I couldn't reproduce it in earlier on my i686 Ubuntu 10.04.1 laptop in Japan. (I meant to indicate that in note #6 earlier.) I've since removed NIS on that laptop, but give me some more time to set up NIS again on the laptop; perhaps I'll be able to compare with what I get on that other computer and track down further.

By the way, if I remove the
+:::
line, NIS seems to still work for groups, and the test succeeds.

You query:

What does `ypcat group' emit?

$ ypcat group
johnchid:x:501:johnchid,rocky,cspathis
sam:x:1011:sam,rocky
slocate:x:516:cspathis,rocky
rajesh:x:1018:rocky,cspathis
bby:x:1012:bby,rocky
ceidata:x:535:root,rocky,mahmoud,john,cspathis,sam
alana:x:1008:rocky
jlsurdilla:x:1017:rocky,cspathis
martin:x:1002:rocky
tester:x:1009:rocky,john
john:x:1004:
rocky:x:1000:
hanu:x:1014:hanu,rocky,mahmoud,john,cspathis
postgres:x:527:rocky
mongrel:x:999:rocky,martin,cspathis,john
devel:x:530:cspathis,rocky,john,jlsurdilla
ron:x:1015:rocky
production:x:1010:rocky
admin:x:520:cspathis,rocky
ceiindia:x:1006:ceiindia,rocky,john,martin,cspathis
mahmoud:x:1001:rocky,cspathis,sam
rich:x:1013:rich,rocky
cspathis:x:1003:rocky
datap:x:998:rocky
bind:x:508:rocky,cspathis,sam,root
datashare:x:1016:rocky,john,cspathis

=end

[naruse (Yui NARUSE)]

• Status changed from Feedback to Assigned
• Assignee set to nobu (Nobuyoshi Nakada)
• Target version set to 1.9.3

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r32242.
Rocky, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

---

• test/etc/test_etc.rb (TestEtc#test_get{pw,gr}nam): skip entries
  start with + sign, which means NIS. these are returned in the
  case that passwd and group entries in /etc/nsswitch.conf are set
  to use "nis" explicitly on Debian. fixed #3683