newgrp in 4.2: missing?
Romain Kang
romain at pyrnj.uucp
Fri Feb 7 00:32:42 AEST 1986
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
More information about the Comp.unix
mailing list