Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!triceratops.cis.ohio-state.edu!karl
From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.unix.wizards
Subject: Re: File daemons
Message-ID: 
Date: 26 Sep 89 18:47:09 GMT
References:  <14609@bloom-beacon.MIT.EDU>
	<16687@watdragon.waterloo.edu> <11154@smoke.BRL.MIL>
	<26629@iuvax.cs.indiana.edu>
Sender: news@tut.cis.ohio-state.edu
Organization: OSU
Lines: 19
In-reply-to: sahayman@iuvax.cs.indiana.edu's message of 26 Sep 89 18:18:46 GMT

sahayman@iuvax.cs.indiana.edu writes:
   A "group daemon" could hand out new
   group ID's as needed, recycle the old unused ones, and so on.
   ...It'd be
   handy to have a group daemon so that I wouldn't have to bug
   the sysadmin every time I needed a special group.

I did this late last year/early this year.  I built a little tool
called "gred" (group editor) which allowed Joe Random User to edit
/etc/groups securely.  It was mildly interesting to a few people, so I
wrote a short paper on it for summer Usenix, but it was rejected (such
is life, ohwell).  It works quite well, but the real restriction is in
the number of groups to which a user may belong.  The largest NGROUPS
I've found is on Pyramids, where it's 20; on Suns and similar things,
it's only 8.  It's necessary to go to a bit of effort to knock NGROUPS
up and recompile everything that uses it, from the kernel up to such
mundane things as initgroups(3) and login(1).

--Karl