Subject: Re: bin/11047: newgrp is missing
To: None <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 04/26/2002 22:55:25
[ On Friday, April 26, 2002 at 16:18:31 (-0600), Rick Kelly wrote: ]
> Subject: Re: bin/11047: newgrp is missing
> Andrew Brown said:
> >yes, we don't have one, but what problem is that? does it do
> >something for anyone that they can't already do?
> It adds a step that a user must do in order to do what he can do now.
On systems with setgroups(2) the 'newgrp' command only changes the
default group (and that inludes Solaris!). So long as your system has
setgroups(2), and your user-ID has membership to all the groups you need
to do your job, and you don't mind leaving your default group as it is,
then you don't ever have to type 'newgrp', whether or not the command
For those people who need a way to change their default group, 'newgrp'
is necessary. With a proper, secure, implementation of
/etc/master.group and all the other sundry bits to manage keeping
/etc/group et al in sync with it (vigrp too?), then it can even be
possible to change your default group to one you're not listed in, which
will effectively give additional group access to those with the
appropriate authentication credentials (and for those which a password
has been assigned, of course).
BTW, adding /etc/master.group is a perfect time to introduce /etc/grp.db
(and of course /etc/sgrp.db) to help out performance-wise on those
systems where there are lots of users and every user has their own group
Greg A. Woods
+1 416 218-0098; <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>