bug in newgrp

[Brant Cheikes]

I think I've finally found a reliable way to reproduce this bug.  I'd
like to hear from others who can reproduce the bug in the manner I'm
about to describe, then maybe folks with maintenance contracts can see
about getting it fixed for the next fixdisk?

I'm running 3.51a on a 3b1 (bug appeared in 3.51 as well).  Memory
size does not seem to matter.  Crucial info: multiple gettys (two, to
be exact) defined in /etc/inittab, hanging off /dev/window (the usual
trick).

Problem description:
 newgrp (or /bin/newgrp) fails to setgrp properly under curious
 circumstances.

To reproduce:
 Log in to the /dev/w1 window, leaving /dev/w2 at the "login:" prompt.
 Type "newgrp foo", where "foo" is a group that you're a member of (as
 listed in /etc/group) other than your login GID.
 You should see "Sorry", and the shell will exit (if you use
 /bin/newgrp, a newgrp'd subshell will not be created).

 Now, log in to /dev/w2.  Switch back to the /dev/w1 window.  newgrp
 will now work.  newgrp will also work on /dev/w2.  As soon as you log
 out of /dev/w2, newgrp will cease to function properly on /dev/w1.

Workaround:
 Always log in first to the LAST getty attached to a window.

So, is it a bug or a feature?
-- 
Brant Cheikes
University of Pennsylvania
Department of Computer and Information Science
ARPA: brant at linc.cis.upenn.edu, UUCP: ...drexel!manta!brant