In libc/nis/nss_nis/nis-netgrp.c (revision 1.12, dated 2004-08-14) line 78 there is an assert(len > 0). If I have an empty netgroup, len==0 and the assertion fails. This can crash, among others, rpc.mountd, resulting in NFS service becoming unavailable. I believe that assert(len >= 0) would be OK. Reproducible: Always Steps to Reproduce: 1. Set up an empty NIS netgroup, use it in an /etc/exports entry (even indirectly, as a subgroup of another netgroup) on an NFS server. 2. Try to mount the corresponding NFS share. 3. Observe that rpc.mountd has died. To see the cause, you can restart it with the --foreground option, then repeat step 2. Actual Results: rpc.mountd crashed with Assertion 'len > 0' failed at nss_nis/nis-netgrp.c:78 . Expected Results: Treated the result from yp_match() as the zero-length string "". It's not illegal to have empty netgroups, nor is it generally useless: such groups can serve as placeholders and may be only temporarily empty. sys-libs/glibc 2.3.4.20050125
has nothing to do with toolchain, assert()'s are bits of code people put in their own code
I also encountered this problem, but only if I mount from a Sun. If I mount from any linux machine, it has no problem. As soon as I mount from a Sun (5.9) it crashes. The problem does not occur with a similar setup on Mandrake (2.6.11.11 kernel with nfs-utils 1.0.6) This is kinda stopping me from switching from Mandrake to Gentoo, and I've been trying to do this since I started working at the place, do I would like to have this increased to blocker.
Gentoo has both nfs-utils-1.0.6 and 1.0.7 so you could simply downgrade
tried 1.0.7, it didn't fix the problem. i will try 1.0.6 and post the results
err...i know this might seem stupid, but _where_ does gentoo have 1.0.6? all i see in portage (and packages.gentoo.org) is 1.0.6-r6 (stable, not working ), and 1.0.7-r1 (tried, still crashing)
(In reply to comment #3) > Gentoo has both nfs-utils-1.0.6 and 1.0.7 so you could simply downgrade It seems I didn't point it out clearly enough in my initial report: the bug isn't in nfs-utils but in glibc. (That's why I stated my glibc version; also, the source pathname libc/nis/nss_nis/nis-netgrp.c should have made it obvious.) You aren't going to get anywhere by downgrading nfs-utils. You will go a long way by fixing the bug in glibc; my original reports tells you which line to change in which file, how, and why. The only caveat is that I haven't tested the change or tried to explore its ramifications elsewhere in the code. The bug is present in glibc CVS head. Will you report it upstream, or shall I do that?
(In reply to comment #2) > I also encountered this problem, but only if I mount from a Sun. I also discovered it while mounting from SunOS (5.8). Haven't tried to reproduce it in other circumstances: this is a production environment, so I simply worked around it by eliminating zero-length netgroups from my NIS map. Your claim that the bug is only triggered by some client OSes surprises me, though: my impression is that only things that matter are the hostname of the client and the contents of the netgroup map. Could it be that your netgroup has a structure like hosts linux sco solaris linux (linux.example.net,,) sco solaris (sun.example.net,,) so that Linux clients wouldn't trigger the bug because the library never gets as far as expanding the empty "sco" netgroup?
Yes, I found it surprising that it only happened just under Sun's and not also Linux. Initially I thought that Solaris is doing something screwed up, but since it works with the outher file servers... Yes, there was an empty group! Although it was _after_ the machines that I was mounting from, removing it solved the problem. Thank you!
Created attachment 65283 [details, diff] glibc-cvs-allow-empty-nis-groups.patch can you guys test this patch against glibc then please ?
The patch does indeed work fine. I created the exact same patch when I discovered this issue and I haven't had any problems.
sorry for being such a tool on this one, filed a bug upstream
this was accepted upstream already and is fixed in latest glibc
