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 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.