Re: user private groups and a src group
Matt Birkholz <birkholz@midnight.com> writes:
> * Set the system default umask to 006 (or 002 I suppose).
002 is the supposedly the most typical default umask, which gives
complete access to the user and the group, and read (and directory
search) access to others. However, in practice, most users set this
to 022 (move the group down the world level) or 077 (full access to
the user only) or 007 (full access to user and group, no access to
world).
> * Set the default group of each user to their own private
> group (e.g. a group with the same name and id as the user,
> whose only member is the user).
I still don't like this idea. Most users have no need for this nor do
most users have the ability to add people to their own special little
group. Groups should have more meaning than, say, the "quinlan"
group. I'm not going to have a group of my friends or something.
Instead, I'll have a "foo" group for the "foo project".
I have no seen any other UNIX does it the way you describe.
> [...]
> * Enroll each source maintainer in a group named "src".
> * Set the group of /usr/src to src. The group of any
> subdirectories created by members of src will default to
> src and the default permissions (again, -rwxrwx--x) will
> allow all members of src to collaborate on maintenance of
> the software in /usr/src.
I *do* like this idea. I also should remind Ian that sman is designed
to be installed as group 'man' as well as all of the manual pages,
just in case he forgets... :-)
> I was a little surprised to see this being promoted, because
> files/subdirectories do not inherit the group of their parent
> directory in SYSV (which, unfortunately, is what Linux tries to be).
> However, this scheme solves an annoying problem and I was anxious to
> try it.
What problem? The src directory? That can be solved independently of
the so-called user's group problem.
> [...]
> Also, the groups command (or Linux itself) doesn't seem to be
> working quite right for root either. `groups` shows the root's
> default private group (root) and six others (bin daemon sys adm disk
> wheel) but not all of them (not users or project).
It shouldn't. root should only be a member of the groups where the
account is explicitly listed as a member.
> [...]
> Perhaps I'm missing a kernel patch that allows a user to be a member of a
> reasonable number of groups (namely, more than 7). I have upgraded to a
> vanilla pl15 kernel. Please let me know if you have patches I need.
See above.
> Does anyone have this private group scheme working? If we can agree
> to use it, a few things in the Debian distribution can be changed to
> provide this functionality by default.
What functionality?
I'm sorry -- maybe I'm totally clueless here, but I don't seen much
inherent advantage in giving each private user their own group,
especially considering how /etc/groups is off-limits to users.
If there are advantages, let's hear them.
Dan
--
Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>
Reply to: