[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: user private groups and a src group

	Date: Fri, 18 Mar 94 01:08 PST
	From: birkholz@midnight.com (Matt Birkholz)
	To: debian-user@pixar.com
	Subject: user private groups and a src group

	      Calling it "the uid==gid proposal" is a misnomer.  Please stop it.

	   Has the proposal changed since Ian Jackson's message of 8 March?
	   I remind you that he wrote:


	If you have an archive of the mailing list, could you summarize the
	(valid) arguments against the proposal?  Are we clear on the benefits?


1.  It clogs up /etc/groups unnecessarily.  Sometimes I want to know what
    groups are out there; currently "more /etc/groups" will tell me without
    making me wade through a list of all the users on the machine.

2.  Some software may break if there are too many groups.  No, I can't name
    anything specific here, but this possibility at least suggests that
    we not jump into this with both feet.

3.  We'll be continually burdened with newbies asking why we adopted this
    weird system.

4.  Many people use SLIP; I plan to be one of them shortly.  They will want
    their user and group setup on their local machine to match or be a
    subset of the user and group setup on the remote machine.  Ditto for NFS.

5.  It has not been fully described.  For example, what happens if I create
    a file in /tmp?  The answer depends on whether a user's primary default
    group is his private group or some larger group.

6.  Not all sites have groups of users collaborating on projects.  What
    percentage do is open for dispute, but certainly it is not a solution
    to a universal problem.

7.  It does not completely solve the problem.  As Remy Card recently pointed
    out in his message, it has no facility for preventing two users from
    simultaneously editing the same file.  For this reason one may even regard
    the proposal as dangerous.

8.  Other solutions exist, viz. RCS.  I have never used RCS myself, as I
    have not collaborated on any software with anyone else on the same machine.
    However, I would like to respond to something that you wrote in response
    to Remy Card's message:

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

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

    This is not explained in the Linux man page, but it is in the Sun man page:

	     The caller of the command must  have  read/write  permission
	     for  the  directory containing the RCS file and read permis-
	     sion for the RCS file itself.  Rcs creates a semaphore  file
	     in  the same directory as the RCS file to prevent simultane-
	     ous update.  For changes, rcs always creates a new file.  On
	     successful  completion,  rcs deletes the old one and renames
	     the new one.  This strategy makes links to  RCS  files  use-

    You seemed to have forgotten something you wrote earlier in your message:

	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.)

    Exactly: using RCS there is no *very* *bad* thing to worry about.
    But if you _don't_ use RCS and instead just have a directory that
    everybody creates group-writable files in, as envisaged in the
    user private groups proposal, then you do have a *very* *bad* thing.

    Regarding "coming full circle", no we have not.  You create the directory
    once and set its permissions correctly, and that's it.  This is a one-shot
    thing (per project).  It does not call for changing your umask.


	[Discussion of retrofitting omitted.]
	It would be persistently tedious every time a
	package installs itself with inappropriate permissions.

Could you elaborate on this a bit?  What packages?  I don't see why
package permissions would be different under user private groups than under
the usual setup.

	If it is this hard to get people to just consider the
	enhancement, I don't want to think about the can of worms
	involved in getting consensus on which groups get access to
	which directories.


	If we take it as the default, why wouldn't we want it to be
	excellent right from the start?

For my purposes it's excellent the way it is, thank you.

	   How 'bout it?

	How about what?  You just told me to pack up my useful default and
	take a hike.  I'm not even sure why.

Funny you should say this.  I was feeling the same way when I posted my
last message.  Ian's been saying that we should pack up the standard Unix
way of doing things, which does work if you know how, and take a hike.
His reasons were (A) we need uid==gid, and because of that (B) it's impossible
to retrofit, so we should put everybody on this system starting from day one.
But you've conceded that (A) is wrong, and nearly conceded (B).

Let's step back for a minute and think about the general situation.
The problem that Ian's method addresses is not specific to Linux; it is
equally likely to happen on any Unix or Posix system.  Ian's solution uses
methods that are not specific to Linux; they could be used on any Unix or
Posix system.  Why has nobody else implemented this as a standard part of
a distributed system?

   (a)  Ian is so much brighter than the the thousands who came before.

   (b)  Solutions to the problem already exist, and they are equally good
	or better.

I'm willing to grant that Ian's solution is quite clever, but mainly
I believe that (b) is the case.

I have no objections to allowing user private groups to be an optional
part of debian, with scripts to switch back and forth.  But maybe you can
give (valid and detailed) arguments why it has to be mandatory.

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

Reply to: