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?
Certainly.
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:
FILES
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-
less.
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.
Huh?
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: