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