Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa Newsgroups: comp.unix.wizards Subject: System V letting random users ch Message-ID: <5486@brl-adm.ARPA> Date: Mon, 23-Mar-87 19:48:41 EST Article-I.D.: brl-adm.5486 Posted: Mon Mar 23 19:48:41 1987 Date-Received: Wed, 25-Mar-87 06:06:27 EST Sender: news@brl-adm.ARPA Lines: 31 From: Guy Harris >>There is no "newgrp" command in 4.[23]BSD; it's not needed. > >Only 16 -/- "newgrp" not needed. > >Really? I know of nobody who has needed "newgrp" under 4.[23]BSD. If you have source, you could boost the maximum group set size; if you don't, you might be able to get your vendor to do so. 64 wouldn't be totally horrible (although you'd probably be advised to change the algorithm for permissions checking, since you probably don't want to linearly scan a 64-element list on every permissions check); if you need to be in that many groups, maybe you should be thinking about adding ACLs to your system instead.... Do you have any evidence to the contrary, or is this just speculation? I think this is an operations/administration problem. Newgrp would be nice for dynamically allowing membership into a specific group, and avoid the runtime-check-all-groups Guy mentions above. On the other hand, it would require a way to dynamically change the passwd on group files (passwd -g?). While this is not a technical problem (btw, did TPC ever hack a program to change group passwords?), it creates the hassle of informing the right people of group password changes. So, it might be nice, but ... (Root Boy) Jim "Just Say Yes" Cottrell I once decorated my apartment entirely in ten foot salad forks!!