newgrp in 4.2: missing?

[Romain Kang]

In article <235 at hadron.UUCP>, jsdy at hadron.UUCP (Joseph S. D. Yao) writes:
> Under 4.2 BSD, processes still have group-id's, the way humans still
> have appendices.  They aren't used for anything I can see.  File access
> is determined by your group vector, rather than your group ID.  (Rather
> a neat idea, but can cause problems, such as ...)  So which group ID
> goes with a created file?  None:  it inherits it from the directory
> in which it finds itself.
> 
> Thus, Berkelians figured that 'newgrp' no longer needed to exist.
> However, right again, this breaks existing code that calls newgrp.
> -flame- .sputter.

And of course, if you decide you *have* to be a member of more than
eight groups simultaneously, you have to recompile the entire kernel.
Also, system performance tends to suffer slightly because the
permission checking mechanism does a linear probe of your group vector
(in the user structure).

Since the user structure gets changed, all sorts of other things in
Unix have to be recompiled, too.  At a site where I once consulted, we
changed NGROUPS from 8 to 20.  We had to rebuild the following stuff:
	/usr/src/lib/libc/gen/initgroups.c
		replace function in /lib/libc.a, /usr/lib/libc_p.a
		initgroups() dependents:
			/usr/src/bin/{login.c,su.c}
			/usr/src/ucb/groups.c
			probably others...
	/usr/src/bin/{ps.c,adb/*}
	/usr/src/ucb/{{w,gcore}.c,dbx/*}
	/usr/src/etc/{pstat,analyze}.c
I probably missed other things.  In retrospect, it probably would have
been quicker to re-implement the newgrp command (even if the shell
didn't fork it directly.)
-- 
Romain Kang, Pyramid Technology Corporation

US Mail:	900 Route 9, Woodbridge, NJ  07095
Ma Bell:	(201) 750-2626
UUCPnet:	{allegra,cmcl2,pyramid,topaz}!pyrnj!romain

"Eggheads unite! You have nothing to lose but your yolks!" -Adlai Stevenson