stein@dolqci.UUCP (Mike Stein) (12/25/87)
I experienced one "gotcha" with the System V 'newgrp' command.
When doing a 'newgrp', you are given a new environment REGARDLESS OF
THE SUCCESS OR FAILURE OF THE COMMAND. What does this mean? After your
'newgrp', all shell variables previously marked for export are no longer
so marked, and all unexported variables are lost. This happens even if
you make a typo and try to change to a group that doesn't exist (e.g.,
'newgrp fo' when you meant 'newgrp foo'.) If you do this and then
correct your typo without re-exporting everything, you end up with no
environment variables left other than the "builtins" (and I'm not even
sure about those).
- Mike Stein
... uunet!vrdxhq!dolqci!stein
U. S. Dept. of Labor / 200 Constitution Ave. NW
Rm. S-4519 / Washington DC 20210 / (202) 535-0640
The above represents the Absolute Truth. Therefore it could not possibly
have been written or approved by the U. S. Government.haque@dg.cs.umn.edu (Samudra E. Haque) (12/25/87)
I just had that happen to me too, except my root shell is /bin/csh.
I had mis-typed "newgrp operator" to "newgrp operatr" and the system gave
me a new csh .. with a standard "%" prompt. That is not what I would have
expected. It should have (at least in my opinion ) gave the Unix "standard"
"Usage: where-in-the-world-did-you-learn-to-type?" message, or maybe
"that group don't exist".
Just an annoyance.. I'm to much used to BSD's su (1) which does switch uid and
executes their .cshrc for you.
Now where did I put that Binary Editor?...
Samudra E. Haque
Computer Science Systems Group, Computer Science Department
University of Minnesota, Minneapolis, MN 55455.
(1)-(612)-625-0876 || haque@umn-cs.cs.umn.edu || haque@umn-cs.UUCPscl@virginia.acc.virginia.edu (Steve Losen) (12/30/87)
newgrp is really a shell builtin command that does this: exec /bin/newgrp group hence the newgrp process replaces the current shell process. Newgrp is a setuid to root program that simply does this: 1) setgid(2) to the desired group (after checking the /etc/group file of course), 2) setuid(2) back to the real user, (we can't let you be superuser, can we?) 3) execs another shell for you. Thus you are left with the same process but it has exec'ed two executables while you were wondering, "Why the hell is newgrp so slow??" Your shell now has a new group id, but you lost your environment in the process. By the way, you can never use newgrp in a shell script because of the exec. The script will never get to the command after the newgrp. -- Steve Losen University of Virginia Academic Computing Center