user private groups and a src group
Date: Sat, 19 Mar 94 16:07 PST
From: vojta@math.berkeley.edu (Paul Vojta)
[...]
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.
Thanks, but please see the logic.txt file referenced earlier.
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.
How (and whether) you organize your /etc/group is up to you. I have
separated the (soon to be) automatically generated private groups from the
project groups and the system groups.
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.
You mean it isn't a simple matter of searching /etc/group? Does the kernel
buffer this file? Is this fear based on anything? I'm glad _some_ Linux
hackers didn't give in to nameless fears and introduced shared libraries
anyway. Personally, _I'm_ not scared. After all, we're using an OS to
which the source is freely available.
3. We'll be continually burdened with newbies asking why we adopted
this weird system.
Compared to the burden of debugging some of the "experts" on this list,
making occasional reference to the Debian FAQ would be a breeze, and
rewarding too. I anticipate a few thank you's from open-minded newbies
that can appreciate the value of the technique.
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.
We haven't made that problem worse.
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.
According to the proposal, the user's default group is his private group.
It seems obvious to me that /tmp is not a directory for whom group-access
is even an issue. The proposal has specified everything that is necessary
to specify. If you want default group access for a project directory tree,
make each directory in the tree setgid=<group>. (If not, don't. Is this
the part that you felt was missing?)
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.
The risk is infinitesimal. The benefit doesn't have to be all
encompassing.
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.
I thought the problem was using the same, default umask setting in project
and home directories without inappropriately (or unexpectedly) widening
access to files in the home directory, or inappropriately restricting
access to files in the project directory. If you redefine the problem as
preventing two users from simultaneously editing the same file, you should
hardly be surprised to find that the proposal makes things worse. If you
didn't want default group access for a directory, why did you make it a
project directory (i.e. setgid=<project group>) in the first place?
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.
Your single example is not an equivalent solution. For starters,
permissions on project RCS directories must be correct in order for RCS to
work. Note that the correct permissions are the defaults in Ian's
proposal. Yes, this can be done by hand. No, that's not a big job. No,
the promise of the proposal is not only in avoiding having to fix RCS
directory permissions. The real promise is in a clean abstraction (project
directories and their contents are, _by default_, accessible to a project).
There's no remembering to frob nothing except the initial specification of
the group associated with the project directory tree.
If you've never collaborated with other people even on the administration
of a machine, then you probably haven't had the annoyingly persistent
problem of changing inappropriately restrictive default permissions on
files. Believe me, it's almost as annoying as this thread.
However, I would like to respond to something that you
wrote in response to Remy Card's message:
[...]
Matthew Birkholz> Does your revision control system run setuid=root
Matthew Birkholz> or something? The RCS that came with Debian 0.91
Matthew Birkholz> doesn't. It can't write files to which it does
Matthew Birkholz> not have write access.
I was asking how he thought his RCS commands were going to write files in
read-only directories.
[...]
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.
An example: I wanted a tags table for the Emacs Lisp standard library.
Currently, I have to run the etags program (assuming Daniel has provided
one, BTW) as root, or "fix" the default permissions on /usr/lib/emacs:
$ find /usr/lib/emacs -print | xargs chgrp wheel
$ find /usr/lib/emacs -print | xargs chmod g+w
$ find /usr/lib/emacs -type d -print | xargs chmod g+s
With this fix and a umask of 002, I don't have to worry that some other
wheel will try to regenerate the tags table only to find that she doesn't
have write access to the file. Without that to worry about, I might
remember what bug in Emacs I was originally trying to track down.
(Actually, I'm not likely to worry about it, until she raps my knuckles for
screwing up. [She's like that, probably because she's my wife. :-])
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?
Maybe /usr/lib/emacs should be writable by wheel, maybe by bin, root, or a
new "emacs" group. Can _you_ imagine getting this list to a consensus on
that issue (and many like it)?
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.
Yes, I guess, in a sense, he is. I thought he explained why. The standard
non-BSD Unix way of doing this is flawed. I thought you had "conceded"
this point when you characterized the scheme as a solution you personally
didn't need. Given that some of us do, why shouldn't we get what we need,
your laundry list of chimerical roadblocks notwithstanding?
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).
Yes, and I "concede" your point that correct default group access doesn't
solve the same problem as does RCS. You can get me to "concede" all kinds
of unrelated or superfluous (e.g. aesthetically motivated) details. You
want uid+100=gid instead? Fine! It's weird, but I'm flexible. :-(Don't I
wish we all were.)
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?
[...]
Ye ol' "never been done before" excuse? You must be scraping the bottom of
your argumentative barrel, but let's step back for a minute and think about
the general argument anyway. Taking the "never been done before" part as a
premise is clever misdirection, but not going to work this time. I'm not
accepting that premise because we've already heard that there are sites
using the proposed scheme. Why do you think BSD works the way it does?
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.
Default group access (a default umask) that is appropriate for creating
files in both project and home directories solves a real problem. Perhaps
not a problem that can be appreciated by someone who has never needed a
project directory.
The cost of the solution is the sight of 's's where traditionally there
were 'x's in the long-format listings of _project_ directories, and a group
name identical to the username where traditionally there was "users" in
long-format listings of home directories. Big deal (NOT).
Matthew Birkholz
birkholz@martigny.ai.mit.com
Reply to: