Re: user private groups and a src group

[vojta@math.berkeley.edu (Paul Vojta)]

At the risk of dragging this discussion out even further, I would like
to dissect Ian's proposal regarding user private groups a bit.

One could consider three changes to debian:

    A.	Both user home directories and project directories are mode
	drwxrwsr-x or drwxrws--- and owned by the appropriate group.

    B.	Each user is given their own private group; their group name
	is the same as their user name; the default umask is 002.

    C.	The gid of a user private group equals the uid of its user.

(I have omitted mention of "Each user is also a member of any additional
`project' groups of which they need to be members" because that is true
anyway.)

It is not stated explicitly in Ian's proposal that some or all debian
packages fall under the category of project directories, but it appears
implicitly in his arguments.  In this message I will assume this to be
the case.

Of course some combinations of A, B, and C don't make much sense:
B doesn't make sense without A, and C requires B.  This leaves:

   o	None of the above
   o	A only
   o	A and B only
   o	All of the above.

Ian proposes "all of the above."

I have been arguing that "user private groups should be optional".
In the context of the above subproposals, let me clarify that a bit.
I should have made this clear earlier, but I don't have strong feelings
either for or against A.  I believe that B should be optional and would
not be hard to retrofit if A is present.  C seems overly meticulous
to me (which I can live with), but it presents problems with
retrofitting B.  I do not object to C it if it is replaced by:

    C'.	When creating a new user with a user private group, adduser
	will choose a uid that is also available as a gid, and set
	the gid of the private group to equal the user's uid.  When
	establishing a user private group for an existing user,
	the gid of the user private group is set equal to the user's
	uid whenever the gid is available; otherwise some other gid
	is used.  (This does not necessarily exclude the possibility
	that one may create a user without their own private group.)

The only arguments that I have seen that retrofitting user private
groups is difficult are:

   --	You will have to consider and possibly change the permissions
	of every directory.  You will also have to change permissions
	every time you install a new debian package.

   Not applicable if A is standard for debian.

   --	You have to make lots of changes to /etc/passwd and /etc/group.

   A script or program can do this sort of thing.

Therefore I propose that we implement A and make (B & C') optional,
with scripts to switch back and forth.

Benefits are:

   o	This provides better support for backward compatibility (e.g.,
	for systems NFS-mounting directories from elsewhere).

   o	Sysadmin's who object to user private groups (in the narrow
	sense of B) are free to do without them.

   o	Maybe we'll actually agree on something :-)

Comments, anyone?

--Paul Vojta, vojta@math.berkeley.edu

PS:  I read Ian's response to my earlier message.  I'll respond to it
separately, but it does seem from that post that his position is closer
to mine than I'd previously thought.  This depends on what he means by
``it wouldn't be mandatory, it would be the default.''