[net.bugs.4bsd] bug in newgrp.c

solomon (02/25/83)

There is a bug in newgrp.c (at least in the version that comes with 4.1BSD).
When doing the "exec" of a new shell, it tries to give the "-i" flag.
However, since it gives it as the second argument to exec, it becomes
argument 0 to the shell, which makes the forked shell to think it's a
login shell, leading to all kinds of strange behavior (for example, it
will fail if you have any stopped jobs).  I'm not sure why newgrp is
trying to supply the "-i" flag anyhow; "su" doesn't use it.
The fix is extremely trivial.
NB:  This fix has only been tested on 4.1BSD and only with csh.

The version of newgrp is

	static char *sccsid = "@(#)newgrp.c	4.1 (Berkeley) 10/1/80";

The changes are

	*** newgrp.c.old	Fri Feb 25 09:48:07 1983
	--- newgrp.c.new	Fri Feb 25 09:52:12 1983
	***************
	*** 45,51
		setuid(getuid());
		for (i=3; i<15; i++)
			close(i);
	! 	execl((pwd->pw_shell[0]?pwd->pw_shell:"/bin/sh"), "-i", 0);
		printf("No shell!\n");
		exit(0);
	  }

	--- 45,51 -----
		setuid(getuid());
		for (i=3; i<15; i++)
			close(i);
	! 	execl((pwd->pw_shell[0]?pwd->pw_shell:"/bin/sh"), "newgrp", 0);
		printf("No shell!\n");
		exit(0);
	  }

guy (02/26/83)

I was under the impression that "newgrp" was deliberately passing the "-i"
flag to the new shell; since the "newgrp" command is equivalent to
"exec newgrp", the new shell is still the process group leader (and hence
still the login shell, sort of, although if the C shell keeps a table
internally of the jobs it knows about, they will of course be forgotten
by the new shell unless the old shell passes the info to the new shell
somehow).  You refer to the new shell as a "forked shell", but newgrp
doesn't fork anywhere, and the Algol 68 shell doesn't fork to execute it;
a quick look at the C shell code indicates that it doesn't seem to either.
"Su" DOES fork to execute a new shell, however, so their behavior is not
supposed to be the same.

I figured that "newgrp" was making the new shell a login shell because
"getty" and "login", curse their pointy little heads, won't permit you
to specify a group name as well as a user name when logging in (i.e., you
respond log in like:

login: guy bin

and you will be immediately put in as group "bin" even though your default
group may be "other".).  This way, for example, if your .profile does any
group-dependent processing, it will be performed again (for example, my
.profile sets my umask depending on what group I am in).

					Guy Harris
					RLG Corporation
					...!decvax!mcnc!rlgvax!guy
					...!seismo!rlgvax!guy

mjb (02/27/83)

People actually still use newgrp? I thought *everybody* wrote an su-like
"sg" to replace it! (I did, the first time I typed "newgrp bazinga", where
bazinga was not a legal group, and found my ass logged off!)

:-) Mike Braca, Brown CS, ..!decvax!brunix!mjb, mjb.brown@udel-relay