Private groups & umask 002 proposal
This message is a summary as I see it of the discussion regarding this
issue, including messages sent out by the listserver to me after about
midnight GMT on Saturday. Anything sent later I haven't seen yet.
--- Here is what I am proposing:
1. Each user gets their own private group. Their gid = their uid
and their group name is the same as their username.
2. Each user is also a member of any additional "project" groups of
which they need to be members.
3. Both user home directories and project directories are mode 2775
or 2770 and owned by the appropriate group. On project
directories the user ownership doesn't matter. (2775 = drwxrwsr-x)
This ensures that new files or directories created there will
inherit both the correct group ownership and the setgid bit.
4. The default umask is 002; if users and/or projects want to keep
their files secret as well as safe they should chmod the
appropriate directories to 2771 or 2770 (drwxrws--x or drwxrws---).
--- Here is why:
This scheme solves a serious problem, namely that directories for
group projects are quite simply unmanageable without it.
I have often been in the position of having to do cp -r on large
directory trees because I couldn't update the appropriate portions.
Numerous times I have had to 'make clean' before I could 'make',
because some of the '.o' files were unreadable and some were
unwriteable.
Having to switch umasks and default groups all the time is even more
of a pain with a nice X workstation than it used to be with a vt220 on
a serial line - now you have not only to remember which host and
current directory an xterm is in, but what the group and umask are as
well. Changing all the time is a nightmare. And as for one's Emacs -
well, am I supposed to have one for each group/umask combination, or
what ?
--- Summary of the debate so far:
Many non-arguments of various forms have been presented.
A couple of people requested clarifications, or details of how
particular problems might be addressed. In each case these were
answered.
The only arguments I have seen against the proposal that weren't based
straightforwardly on fallacies, misconceptions or mistakes are:
- You need to mess about with the /etc/group file to give
everybody their own group.
This seems to me to be an extraordinarily weak argument. This is a
minimal cost compared to the convenience benefits the proposal gets
you. In fact, my proposal is the thing that makes the /etc/group
file important at all on a system.
- People may `piss in their pants' as Matt put it when they
see the `s' where they're used to seeing an `x' in their ls -l.
This is even weaker, and can easily be solved by documentation.
- It's "non-standard".
This isn't true. There is no "standard" way of doing this,
precisely because this kind of decision is so often made by
the local administrator or distribution provider. It is perhaps a
little unusual, however I have seen it done quite often - it is a
solution that has been independantly reinvented several times at
least to the knowledge of just the people who posted here on these
lists, and in each case it has been found to work well.
- It's unnecessary.
I can personally testify that I have worked on several systems
where it hadn't been done but would have been a great boon, and on
others where it was implemented and was very useful. These
examples weren't bizarre local things, but straightforward
informally managed projects usually involving software development.
Given that it is definitely necessity for some people, in order to
oppose it successfully one should show that it causes genuine
problems for some of the people for whom it isn't necessary.
I'm still waiting to see one worthwhile argument against my proposal.
I don't expect to see one.
Ian.
Reply to: