Aucbvax.3027
fa.unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Wed Sep 9 20:57:28 1981
chgrp
>From eps@UCLA-Security Wed Sep 9 20:47:56 1981
If chown(2) resets the setgid bit if the new group is not the
same as the effective group then there is no problem. The
kernel does not (and should not) have knowledge of what groups
a person can newgrp into. Newgrp is one of those things I don't
really like; it doesn't "change your group" as the manual page
would seem to imply; it is execed by the shell, and in turn
execs a new shell. You lose your unexported shell variables
when this happens. I do not export my prompt (I hate $ because
it reminds me of cretinous VMS), so my top-level shell is
easily identifiable. I usually use newgrp like su; (newgrp group)
to make a subshell using that group, and set the prompt for that
shell to '(group) '. It would be nice if this could be automated,
but of course it doesn't work to put newgrp in a shell script!
Solutions? Allow newgrp to be invoked as 'newgrp - group'
akin to su to cause the new shell to be execed with argv[0]
set to "-newgrp" and then put a case $0 in my .profile.
What if process-related calls other than kill and ptrace
took pid as an argument (shades of TWENEX). I'd love to
be able to do getppid(pid). How about setgid on behalf
of another process? Then newgrp really could change your
group!
--Eric
P.S. Csh fanatics need not reply to this
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
