Bug 96370 – mountd crashes with Assertion 'len > 0' failed on empty NIS netgroup

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Sergio Gelato 2005-06-17 05:30:49 UTC]

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

[Comment 1 SpanKY 2005-06-17 06:36:30 UTC]

has nothing to do with toolchain, assert()'s are bits of code people put in
their own code

[Comment 2 Cosmin Nicolaescu 2005-06-23 17:38:14 UTC]

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.

[Comment 3 SpanKY 2005-06-23 19:07:59 UTC]

Gentoo has both nfs-utils-1.0.6 and 1.0.7 so you could simply downgrade

[Comment 4 Cosmin Nicolaescu 2005-06-23 19:09:30 UTC]

tried 1.0.7, it didn't fix the problem.

i will try 1.0.6 and post the results

[Comment 5 Cosmin Nicolaescu 2005-06-23 19:11:01 UTC]

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)

[Comment 6 Sergio Gelato 2005-06-24 03:48:15 UTC]

(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?

[Comment 7 Sergio Gelato 2005-06-24 04:05:19 UTC]

(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?

[Comment 8 Cosmin Nicolaescu 2005-06-24 05:46:05 UTC]

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!

[Comment 9 SpanKY 2005-08-06 21:16:22 UTC]

Created attachment 65283 [details, diff]
glibc-cvs-allow-empty-nis-groups.patch

can you guys test this patch against glibc then please ?

[Comment 10 Cosmin Nicolaescu 2005-08-07 11:39:04 UTC]

The patch does indeed work fine. I created the exact same patch when I
discovered this issue and I haven't had any problems.

[Comment 11 SpanKY 2005-08-09 22:25:40 UTC]

sorry for being such a tool on this one, filed a bug upstream

[Comment 12 SpanKY 2005-12-14 10:32:12 UTC]

this was accepted upstream already and is fixed in latest glibc