[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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

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.


Reply to: