user private groups and a src group

[birkholz@midnight.com (Matt Birkholz)]

   Date: Wed, 16 Mar 94 16:43 PST
   From: "Remy Card" <card@masi.ibp.fr>

   [...]

	   Now, let's think carefully about a common project development
   involving a team of cooperating users.  If the users all share
   read-write access on the project files, there is a great risk of
   inconsistency (users A and B can modify the same file and the changes
   made by A can be overwritten by the changes made by B).  In this case,
   the write access can be a *very* *bad* thing and is not an advantage at
   all.

RCS handles the file permissions correctly (most of the time), assuming
everyone in the project has write access to the directories.  You should
try it sometime.  It's quite slick.  When a file is not checked out, the
permissions are read-only for everyone.  When a file is checked out
(locked), the owner of the file becomes the person who checked it out and
the permissions are owner read/write, group read-only.  There is no *very*
*bad* thing to worry about -- other than getting the group permissions on
the directories right.  (I think we've come full circle, again.)

	On the contrary, if you provide the developers with read-only
   access [...]

I doubt that having _no_ write access is a solution.

   [...]

	   So, as a conclusion, IMO:
	   1. write access to a common set of files by a development team
	      is not needed (and not even desirable) to achieve a project
	      with efficiency,

Does your revision control system run setuid=root or something?  The RCS
that came with Debian 0.91 doesn't.  It can't write files to which it
does not have write access.

	   2. thus, there is no need for `non standard' umasks for members
	      of the development team,

Which standard is that?  (I think you mean "non-customary" or
"non-traditional".)  I can take tradition or leave it.  Usually, I leave
it.

BTW, much has been made of the fact that certain users might wet their
pants if they see an "s" where they're used to seeing an "x".  I'd like to
make much of the "fact" that certain other users will say "Cool!  Groups
work!".  Much has been made of the fact that certain sysadmin's will be
annoyed that they will have to touch the /etc/group file.  I'd like to make
much of the "fact" that certain sysadmin's will be impressed that the
/etc/group file is actually important.  If _some_ of these are "arguments",
they _all_ are.

	   3. thus, I think that the uid==gid proposal is unneeded.

uid==gid is a convenience.  It is not needed to implement the proposal.
Calling it "the uid==gid proposal" is a misnomer.  Please stop it.
If you are going to have a private group per user, what gid's would you
pick?  (Hint: "gid=random(uid)" is _not_ a good answer; "gid=identity(uid)"
is a good answer.)  (Double hint: That was a rhetorical question [and a
rhetorical hint, I suppose]. :-)

	   Of course, I'll be glad to hear about counter examples
   (important projects which cannot be achieved with the help of a version
   control system and which require a change in the uid and gid
   attribution).

Well, _my_ project is "important" (to me) and so is my time.  (Bye.)

Matthew Birkholz
birkholz@martigny.ai.mit.edu