mg@GODZILLA.CGL.RMIT.OZ.AU (Mike Gigante) (11/24/90)
On Berkeley multiple groups, I would like multiple groups to be active automatically. As I understand it from reading the release notes and the manual entry for 'multgrps', it is started as a subshell just like newgrp(1) I suppose I could just put multgrps in /etc/passwd, but that seems crazy I would have to manually set the env variable SHELL back to /bin/csh in the .login (or whatever) (I just tried changing a user's login shell to /bin/multgrps and it just started eating CPU time and didn't successfully login.) Any other suggestions? Is there any intention of making multiple group support the default? Mike Gigante, RMIT Australia
kipp@warp.esd.sgi.com (Kipp Hickman) (11/27/90)
In the next major software release, wsh will support multgrps directly. kipp
bowen@wanda.SGI.COM (Jerre Bowen) (11/27/90)
In article <9011230236.7542@godzilla.cgl.rmit.oz.au>, mg@GODZILLA.CGL.RMIT.OZ.AU (Mike Gigante) writes: > > On Berkeley multiple groups, I would like multiple groups to be active > automatically. As I understand it from reading the release notes and the manual > entry for 'multgrps', it is started as a subshell just like newgrp(1) > > I suppose I could just put multgrps in /etc/passwd, but that seems crazy > I would have to manually set the env variable SHELL back to /bin/csh > in the .login (or whatever) > > (I just tried changing a user's login shell to /bin/multgrps and it > just started eating CPU time and didn't successfully login.) > > Any other suggestions? Is there any intention of making multiple group > support the default? > > Mike Gigante, RMIT Australia In our next release multiple groups will be activated by default in all entry points to the system. Meanwhile, we activate them on a per-user basis by adding 'exec /bin/multgrps' as the LAST LINE of the .login file. Jerre Bowen
mike@BRL.MIL (Mike Muuss) (11/27/90)
I don't believe that WSH is the proper place to initialize MULTGRPS.
Rather, I believe that MULTGRPS should be enabled or disabled when
the user first contacts the system. Therefore, it should be
done in LOGIN, RSHD, and FTPD. At a minimum, the system administrator
should be able to configure this behavior (on or off) on a system-wide
basis; if you want to sucumb to creeping-featurism ("feeping-creaturism!"),
you might make it selectable by user ID, for "optimal managerial
flexibility" (bletch).
Best,
-Mikeadam@gpu.utcs.utoronto.ca (Adam R. Iles) (11/27/90)
In article <1990Nov26.214307.10874@odin.corp.sgi.com> bowen@wanda.SGI.COM (Jerre Bowen) writes: >In article <9011230236.7542@godzilla.cgl.rmit.oz.au>, >mg@GODZILLA.CGL.RMIT.OZ.AU (Mike Gigante) writes: >> >> Any other suggestions? Is there any intention of making multiple group >> support the default? > > Meanwhile, we activate them on a per-user basis by adding 'exec /bin/multgrps' >as the LAST LINE of the .login file. I did this when we first got 3.3.1 up on our 340. There are two important points that I think should be made about this. 1) The shell will no longer know that it is a login shell. Thus the logout and login commands will not work and the ~/.logout file will not be run. 2) If the user issues the command 'exec login' to log into another account ALL of his multiple groups will STILL be active on the account that he logs into. Not too secure eh? :-( I will not put the 'exec /bin/multgrps' command in another users .login because of these problems. I hope that the next release will fix these problems. -- Adam R. Iles: adam@epas.utoronto.ca Cut back on CO2 emissions -- Stop breathing :-)