bin/49283: lib/libc/gen/t_getgrent:getgrent_loop isn't deterministic if hooked into an auth backend in flux, can timeout, etc

[yaneurabeya%gmail.com@localhost]

>Number:         49283
>Category:       bin
>Synopsis:       lib/libc/gen/t_getgrent:getgrent_loop isn't deterministic if hooked into an auth backend in flux, can timeout, etc
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 14 06:15:00 +0000 2014
>Originator:     Garrett Cooper
>Release:        n/a
>Organization:
EMC / Isilon Storage Division
>Environment:
n/a
>Description:
The lib/libc/gen/t_getgrent:getgrent_loop testcase counts the number of groups iterated over with getgrent by counting the number of iterations, calling setgrent to rewind the database, then force the database to be reopened by calling endgrent, then getgrent in a loop.

There are a couple issues that come to mind with this testcase:

- If the groups change between any of the 3 phases, the testcase will fail with little to no helpful diagnostic info.
- If there's a large group database or the auth backend is slow, the testcase can timeout.
>How-To-Repeat:
Mangle /etc/group while running the testcase or do the equivalent with the NIS/YP backend.
>Fix:
It would be nice if getgrent could operate on files, file descriptors, or other things, so it could be unit tested a bit better.