NEW PROPOSAL

[birkholz@midnight.com (Matt Birkholz)]

   Date: Sat, 26 Mar 94 21:13 PST
   From: stephen.white@adam.com.au

   I would like to present a new idea for 'private groups'.

   First, I'd like to give my understanding of the situation to be sure I
   have it completely right.

   [...]

Right!

   My proposal:
     /home
     /home/fred (fred,private)
     /home/jack (jack,private)
     /home/jill (jill,private)
     /home/proj (root,proj)
      ^^^^--------------------Is this kosher (according to FSSTND)?

   [...]

   This arrangement with the single "private" group eliminates the need
   to have a group per user, and therefore eliminates the need to
   synchronise /etc/password and /etc/group with a scheme like uid=gid.

There was never a "need" to "synchronize" /etc/passwd and /etc/group.  That
was an aesthetically motivated choice.

Your scheme adds the requirement that home directories be setgid=private,
yes?  It would seem that there is a tradeoff: eliminate a group per user,
or eliminate setgid home directories.  (I don't really care which is
chosen.)

   This in turn eliminates the extra problems with NFS mounting and most
   of the other objections that have been raised against private groups,
   whilst still retaining the same usage and all the benefits that
   private groups offered.

I don't see this.  I think you've added a possible objection while
eliminating one.  What are the "extra problems" with NFS mounting?  Don't
you have to copy the site's /etc/passwd and /etc/group in either case?

   Furthermore, someone has been very clever and prevented chmod from
   setgid'ing a file if you do not belong to the group (even if you do
   own the file). This eliminates that possible security hole.

This sounds like a source of confusion, e.g.: how come I can't make this
file, that I mistakenly created in /usr/proj, private?
	$ chgrp private file
didn't work!

Interesting idea, though.

Matthew Birkholz
birkholz@martigny.ai.mit.edu