Re: user private groups and a src group

["Remy Card" <card@masi.ibp.fr>]

	Hi,

	Sorry, I missed the start of this thread but I think that I
have to comment now.

	First, I'll try to sumarize my understanding.  Since some users
may cooperate on a project, they have to work (with read and write access)
on the same set of files.  To ensure that they have write access, they must
set their umask to 002 or 007 and all their files are group writable if
they are too lazy to change their umask when they stop working on the
common project.  Creating a group for each user eliminates the security
problem, right ?

	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.

	On the contrary, if you provide the developers with read-only access
to the project files, each user will be able to extract files from the
common set (let's assume that this extraction sets a lock on the common file
to avoid possible inconsistencies).  Then, he/she will be able to change
his/her copy of the file and then replace the common file (and remove the
associated lock).  In this case, the read-only status of the common files
and the locks are a *big* *win* since it avoids concurrent access to the
same files.

	Of course, this scheme requires a bit of discipline from the
developers and adds some constraints (users have to use special commands
to extract and files) but a big project cannot be managed as a single
person project.  After all, RCS (Revision Control System) and CVS (Concurrent
Versions System) have been designed to ease the task of a set of cooperating
developers (RCS and CVS manage the access rights of the common files) and
I don't understand how an important project could be conducted with anarchy
(everyone has the right to modify any files) when one can follow the rules
of software development and benefit from the help provided by the versions
control systems.  If you still doubt, take a look at some important softwares:
the Mach team uses RCS, the FreeBSD and NetBSD teams use CVS, the Kerberos
team uses CVS, the FSF uses CVS and Linux kernel developers use Linus
Torvalds as a coordinator (OK, Linus is not a version control system but
he is the only person have write access to the kernel source and corrects
the conflicts in the changes sent by other developers).

	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,
	2. thus, there is no need for `non standard' umasks for members
	   of the development team,
	3. thus, I think that the uid==gid proposal is unneeded.

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

		Remy