Re: user private groups and a src group
As I'm the one who originally brought up the scheme, I'll summarise
what I propose (at the cost of repeating some things that have already
been said):
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---).
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 ?
Daniel Quinlan asks:
> This seems like an awfully ugly hack for something that could be fixed
> with a shell script or two on a local basis or perhaps even a low-level
> change.
Well, the low level change might be equivalence of uids and gids
(Hurd, anyone?) but I don't think we're ready for that. And even if
we were, this would be the first step towards it.
Scripts just don't cut it. For starters, they either produce
subshells which must be tediously nested, or have to be sourced or
whatever and are thus a right royal pain.
> This doesn't seem like the kind of thing that Debian, still in
> development, should be trying to do. I admit that the single benefit
> is nice, but I see this as an exhibition of a "creeping feature" --
> something that will cause us more problems in the long run than
> anything else.
You appear to be under the impression that this is an experimental
feature. It is not - it is used on many systems I have come across,
my own installation included, and is rock solid and very useful.
The one major system I came across recently where it wasn't done
wished they had done it, but they couldn't now because they'd already
assigned the uid/gid numbers and they were too hard to change.
> Not many Linux users will have a use for it
This is false. For an example everyone can get to grips with, it
allows members of the `src' group to recompile the kernel without
having to mess around with umasks, strange shell incantations, etc.,
and without having to su to root (principle of least privelige).
> and fewer still will understand it.
Nonsense. Having a default umask of 077 or 022 (or 007 or 002 and no
private user groups) *definitely* violates the principle of least
surprise when dealing with shared directories.
The scheme I am proposing does the right thing almost every time
(sometimes `tar' can catch you out, but that's always going to be a
problem).
> More trouble and ugliness than it is worth. We should
> be worrying about fixing bugs, not creating new ones.
It's neither troublesome nor ugly and it does not create new bugs.
Please can we have this in before Debian 1.0 - otherwise we're going
to find it virtually impossible to migrate, because all the
installations will already have groups with the gids we're going to
need to use. This arrangement is quite hard to retrofit, but very
easy and straightforward to do from the beginning.
Ian.
Reply to: