extra groups passed by openssh - security issue?

[Martin Schulz]

I would appreciate your opinion on a problem with sshd on Linux,
when running under daemontools supervise.

The configuration:
sshd version OpenSSH_3.7.1p2
Redhat Linux 2.4.20-8smp #1 SMP  i686
supervise / daemontools-0.76

I see the following behavior regarding groups:
-bash-2.05b$ ssh mschulz at localhost id -Gn
id: cannot find name for group ID 201
id: cannot find name for group ID 2039
OA3  201 2039

The group my account belongs to is OA3, groups 201 and 2039 do not exist..
(a normal login or su, and 'id -Gn' works as expected)

It turns out that when I run sshd standalone (debug), it works fine - 
only when
run under the supervise command I see the strange extra groups.

This is not related to SSH privilege separation, the install is correct 
and works fine
with respect to the sshd privilege separation user. (I've looked through 
the strace
output).
 
Between different user accounts, the problem occurs often with the exact 
same behavior,
but for some there is only one different extra group ID, or none at all.

Is this a known problem?
Can anyone confirm it?

Looking at the source, it appears that great care is taken to _remove_
all extra groups before starting subprocesses, and indeed  if I look at the
exact same configuration on Solaris 8, there are no extra groups.

Is this a compile option problem?  I have
#define HAVE_SETGROUPS 1
and everything looks proper to me.

Am I looking at a bug or two?
Is there a some unit testing code for the uid and privilege switching 
code I could
run?

Any simple things I should try with supervise?

I am ancious to exclude any security issues related to this issue.

I am relatively reluctant to 'experiment' on this box, as it is our 
company's main CVS server,
making use of groups to control write access.

Thanks a lot.

   Martin